4 ms·

That's not true at all, have you ever actually done kernel development, especially dealing with bad hardware? A kernel panic is what it is no matter how many bo

• jacquesm 18y ago
  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.