Date: Mon, 10 Jul 2000 17:18:44 +0100 From: Paul Richards <paul@originative.co.uk> To: Nick Hibma <n_hibma@calcaphon.com> Cc: Warner Losh <imp@village.org>, new-bus@FreeBSD.ORG Subject: Re: Debugger vs panic Message-ID: <3969F764.E181C7CE@originative.co.uk> References: <Pine.BSF.4.20.0006271149030.13143-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Nick Hibma wrote: > I'm still catching up with mail I have backed up from the Perl cruise so this is a little late. > I've made this exact same comment to dfr about 1.5 years ago, to replace > the panics with appropriate empty returns, returning NULL or false in > most cases. > > He was quite persistent in his opinion that it was a bug in the code and > could only lead to faults later in the code. He'd rather have the > problem pointed out right where it occurs. And I agree with him to the > extent that if there is a problem it should go pop as early as possible > in the appropriate place, and not at a later stage where you will have > to trace back to the place where the value was last written, which might > be complicated to say the least. I noticed there were a lot of places in the code that paniced when they should really return failure codes as well. I don't agree with Doug's standpoint though. Panic's are becoming over used in the kernel to catch assert type conditions and really they should only be used in those cases where to continue would be catastrophic i.e. corruption of data or hardware failure might occur and for situations where no other action is possible. In most cases the driver code can safely return a failure code and the likely outcome will be an attach will fail or something equally benign will happen and that would be just as useful from a development point of view since it will be clear something is wrong. If you want to use panics for debugging purposes then they should be enclosed in #ifdef DEBUG or at the very least INVARIANTS. The kernel should never panic if it is possible to safely continue, otherwise we make the OS less stable to adverse situations rather than making it a more robust OS. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3969F764.E181C7CE>