Peut-être qu'en faisant des trucs tordus on pourrait y arriver vaguement (mais la complexification que cela induirait aurait ses propres bugs qui ôteraient tout intérêt), mais ce qu'il faut bien comprendre c'est qu'un module de noyau monolithique n'est _PAS_ analogique à un processus serveur de micro noyau.
Par exemple un module implémentant un pilote va typiquement enregistrer un ISR, gérer des appels synchrones en provenance de l'userspace, et des fois lancer des threads perso ou autre mécanisme d'exécution asynchrone (tasklet, etc...). Il va de plus s'allouer tout un tas de ressources qui ne sont pas forcement managées (je crois qu'il y a un peu de management possible dans les Linux modernes).
Les oops que tu vois avec backtrace sont dans un contexte en provenance de l'userspace. Le noyau tente dans ce cas d'éviter de paniquer, en tuant le processus appelant (et encore, uniquement quand certaines conditions sont vérifiées). Ce n'est qu'une manière de mitiger le problème ! Si tu vois un kernel oops, sauf si tu es absolument sûr de toi (donc entre autre que tu connais _très_ _très_ bien le code correspondant), sauve tout ce que tu peux et reboot immédiatement !
Maintenant si un pb se produit dans une ISR, ... il n'y a rien d'autre de malin à faire que de paniquer.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 2.
Par exemple un module implémentant un pilote va typiquement enregistrer un ISR, gérer des appels synchrones en provenance de l'userspace, et des fois lancer des threads perso ou autre mécanisme d'exécution asynchrone (tasklet, etc...). Il va de plus s'allouer tout un tas de ressources qui ne sont pas forcement managées (je crois qu'il y a un peu de management possible dans les Linux modernes).
Les oops que tu vois avec backtrace sont dans un contexte en provenance de l'userspace. Le noyau tente dans ce cas d'éviter de paniquer, en tuant le processus appelant (et encore, uniquement quand certaines conditions sont vérifiées). Ce n'est qu'une manière de mitiger le problème ! Si tu vois un kernel oops, sauf si tu es absolument sûr de toi (donc entre autre que tu connais _très_ _très_ bien le code correspondant), sauve tout ce que tu peux et reboot immédiatement !
Maintenant si un pb se produit dans une ISR, ... il n'y a rien d'autre de malin à faire que de paniquer.