When the kernel panics, it can enter ddb or reboot. There could be another mode implementing a blob (animal) approach this way:
At startup, userconf(4) [1] parses an array of instructions compiled in by config(1), then processes, for arch supporting this, instructions passed by bootinfo and enters eventually an interactive session. For this interactive session, userconf(1) could register the modifying commands in a memory zone accessible by the other routines (at the moment, there is a history recorded but in a static array with no use at all). When the kernel continues, before climbing down a dev node, a "disable this" (shorten as "D this") could be added in this shared zone. If everything goes well, the next node will erase the instruction with its own. If something goes wrong, the panic will add a "print <debug info>" (shorten as "P <debug info>") and there could be a third mode: instead of entering ddb or rebooting, the kernel restarts: it is not reloaded it restarts from the beginning. The userconf replays: instructions compiled in by config(1), bootinfo ones, no interactive session but replaying the instructions in the shared zone, thus disabling the offending device. Then the kernel continues and will worm its path avoiding this panicing point until, eventually, reaching userland, when remote connections can be done and displaying what instructions (and what debugging informations) are in the shared zone. So: trial/error but if error, trying another path. Or, instead of trying artificial intelligence, trying natural one. [1] This is the userconf(4) I have modified: https://github.com/tlaronde/netbsd-src/tree/tsjl -- Thierry Laronde <tlaronde +AT+ kergis +dot+ com> http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
