From owner-freebsd-alpha Fri Oct 16 00:14:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23714 for freebsd-alpha-outgoing; Fri, 16 Oct 1998 00:14:18 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23645 for ; Fri, 16 Oct 1998 00:13:55 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id OAA16113; Fri, 16 Oct 1998 14:44:22 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810160644.OAA16113@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith cc: dg@root.com, freebsd-alpha@FreeBSD.ORG Subject: Re: kernel traps on boot.. In-reply-to: Your message of "Thu, 15 Oct 1998 23:02:23 MST." <199810160602.XAA00878@dingo.cdrom.com> Date: Fri, 16 Oct 1998 14:44:21 +0800 From: Peter Wemm Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: [..] > > 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. > > I don't think anyone would disagree with you here. However an unaligned > access doesn't fit into this case, as you can handle it cleanly (while > tagging the problem as an error) without crying wolf. I completely agree for what it's worth. NULL dereferencing is not the same as an unaligned access. There is no clear recovery process for NULL dereferences, the only sensible thing to do is to panic before things get too bad. The system is well and truely off the rails by now. However, with a kernel that was written in a 32 bit environment is is evolving to 64 bit, it's only natural that some code will run afoul of new restrictions. If the only thing that is wrong is the alignment and recovery is possible (although inconvenient), then there's no *benefit* in panicing with dirty filesystems, etc. If you have lots of people pounding on it, you're going to find out about alignment problems in code that you rarely excercise. Sure, excercising test code and regression testing is nice, but it's a luxury we don't yet have. If the system panics on an unaligned accesses and there are some scattered around, you can be sure that people won't be sticking their necks out to play with it. Anyway, it's not worth arguing about this. We're bound to have them still, but it's only a young port and not exactly production grade yet. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message