Date: 14 Oct 1998 18:59:18 -0700 From: cgd@netbsd.org (Chris G. Demetriou) To: dg@root.com Cc: Jason Thorpe <thorpej@nas.nasa.gov>, Andrew Gallatin <gallatin@cs.duke.edu>, Chris Csanady <ccsanady@friley-185-114.res.iastate.edu>, freebsd-alpha@FreeBSD.ORG Subject: Re: kernel traps on boot.. Message-ID: <8767dmoaa1.fsf@netbsd1.cygnus.com> In-Reply-To: David Greenman's message of Wed, 14 Oct 1998 17:54:45 -0700 References: <199810150054.RAA05491@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman <dg@root.com> writes: > >Just doing printfs for broken kernel code only encourages laziness. > > Well, that might be fine for a developer, but it sure doesn't help end > users. We *are* trying to provide a production system after all. :-) If code is sufficiently untested that it randomly runs into unaligned accesses, then by definition, it isn't a production-quality system and you don't need to worry about panic()ing. However, if it _is_ well tested, "production quality," and still runs into that unaligned access, then that unaligned access is probably indicative of a somewhat-serious bug. It means either that code is getting a bogus value because of specification/implementation "issue," or that something, somewhere got corrupted, and therefore the system lost. To have such bugs fixed properly, in many cases, a developer will need to know more about the context in which it occurred than just the fact that it occurred, the PC, and a few registers. That means panic, followed by kernel core dump (or invocation of kernel debugger, or whatever), which then gets handed by the user of the production system to a developer, who debugs it. In my opinion, it's not only bad, but _irresponsible_ to let the system bumble on in the face of such a bug. High uptime is nice, but if it comes at the cost of ignoring serious system errors or corrupting data, it's worthless. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8767dmoaa1.fsf>