Kernel startup: the blob (animal) approach

[tlaronde%kergis.com@localhost]

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