Yes, and yes, and you're wrong about that. Anything else :) ?
To elaborate: Yes, I've actually written an os, yes, bad hardware was my 'standard' in those days (a simple lack of money), imagine a pc built out of parts bolted to an old print-file trolley, more flakey than I care to remember.
A kernel panic in a microkernel presumes a memory or a cpu error, anything else the kernel simply does not deal with so that would lead to driver process issues, not kernel panics.
A faulty memory controller or cpu would lead to a kernel panic because of (apparent) datastructure inconsistencies.
One of the hardest drivers to write (even in a microkernel environment) was an X.25 board that a friend of mine had designed around some comm chip, for one the X.25 spec is pretty convoluted and there were a lot of layers of the protocol to be implemented in a single driver. That thing was an absolute nightmare to debug, other than that most drivers (harddisk controller, network cards, graphic boards) were a walk in the park compared to doing the same under a macro kernel.
Simply telnet in to the machine, start up the vga driver process and run it (under the debugger) until you manage to crash it. Most of the times a simple 'where' and close inspection of the source would be enough to solve the problem, recompile and run for the next iteration. No kernel panics.
To elaborate: Yes, I've actually written an os, yes, bad hardware was my 'standard' in those days (a simple lack of money), imagine a pc built out of parts bolted to an old print-file trolley, more flakey than I care to remember.
A kernel panic in a microkernel presumes a memory or a cpu error, anything else the kernel simply does not deal with so that would lead to driver process issues, not kernel panics.
A faulty memory controller or cpu would lead to a kernel panic because of (apparent) datastructure inconsistencies.
One of the hardest drivers to write (even in a microkernel environment) was an X.25 board that a friend of mine had designed around some comm chip, for one the X.25 spec is pretty convoluted and there were a lot of layers of the protocol to be implemented in a single driver. That thing was an absolute nightmare to debug, other than that most drivers (harddisk controller, network cards, graphic boards) were a walk in the park compared to doing the same under a macro kernel.
Simply telnet in to the machine, start up the vga driver process and run it (under the debugger) until you manage to crash it. Most of the times a simple 'where' and close inspection of the source would be enough to solve the problem, recompile and run for the next iteration. No kernel panics.