> There is an overall point here: real operating systems do not crash,
> unless,

> 1. there is a bug in the OS. (Such bugs are not to be tolerated, and
> must be fixed)

Assuming they can be found, of course.  I _know_ there is a bug in at
least one of fsck and the kernel, because I've seen a filesystem pass
fsck without a peep and then panic the kernel when used.  But I don't
know enough about the relevant structures to even look at the
filesystem and determine which the bug is in, never mind actually
finding it once that's done.

> The point is that it should be *impossible* for a normal user to
> crash the system [...]

...by any means whatsoever.  (Electronic means, of course; resorting to
hardware kludges like pulling the power cord doesn't count. :-)

> The superuser is a special case, because UNIX allows that user vastly
> more latitude to do things. Clearly:

> % cp /dev/null /dev/mem

> will eventually crash the system.

Well...even if I take you to mean /dev/zero, on machines with physical
memory that doesn't start at zero, you'll get a write error right away.

> Don't ignore the list of panic calls that was grep'd from the sources
> earlier in this discussion - the question is, given that list, are
> all of them reasonable responses to the condition that the code
> discovered at that point?  We should go through each one and
> re-evaluate from time to time, to make NetBSD more robust and
> reliable.

Indeed we should.  Among many other things we should do.  Personally,
making sure all the panics are really can't-happens rather than
recovery-is-more-than-I-feel-like-writing-now is pretty low on my
priority list.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu