Date: Wed, 12 Dec 2012 16:02:58 -0800 From: Navdeep Parhar <np@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: Adrian Chadd <adrian@FreeBSD.org>, src-committers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, svn-src-all@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <50C91B32.4080904@FreeBSD.org> In-Reply-To: <50C909BD.9090709@mu.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <CAJ-Vmo=U04GX%2BZyKuzXLwV%2BPpzU6_dm5BCmL=DWfsmhTVAR%2BsA@mail.gmail.com> <201212121658.49048.jhb@freebsd.org> <50C90567.8080406@FreeBSD.org> <50C909BD.9090709@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/12/12 14:48, Alfred Perlstein wrote: > On 12/12/12 2:29 PM, Andriy Gapon wrote: >> Now we get a new middle-ground: get both worse performance (because >> KASSERTs are compiled in) and a risk of harming your data (because >> KASSERTs no longer panic). The upside: there is no panic! There's just >> a log message (or etc). and chance to get more log messages because >> the insanity propagates. And a chance to lose your data (your >> customer's) - but I've already mentioned this. I am not sure that I >> like this kind of middle-ground. > I have a number of points here: > > The most important one being: > 1) without kassert you would still have the bug, just that it would be > unreported. > The upside: there is no panic! There's **NO** log message (or etc). > and chance to get more log messages because the insanity propagates. > > Terrible! > > Let me explain that again: > If you don't compile in KASSERT, then it's not like the condition is > never going to happen. Instead it will just be unreported. A KASSERT() really is for a condition that should never happen. It is primarily useful during development and testing (and when the code is reworked or redesigned). I agree with Andriy here -- a non-fatal assert shouldn't really exist. Why not add a new facility (a "if (!foo) kdb_backtrace()" or similar), call it what you want to, enable it (or not) even in release builds if you want to, use it wherever you want to, but let KASSERT be just the way it is? Adding a global knob that changes the way KASSERT behaves risks tripping others up. Personally, in a debug kernel I _really_ want the kernel to stop right away if any KASSERT in my code goes off so that its state is as close as possible to what it was at the time the problem occurred. In a release kernel I _really_ do not want the overhead of the KASSERT at all. If it was a check for a condition I wasn't sure about then I wouldn't have written it as a KASSERT. That's my 2 cents in case you plan to revisit your changes and were looking around for inputs... ;-) Regards, Navdeep > > So to put it in your own words, *without* KASSERT you get: > > The upside: there is no panic! There's **NO** log message (or etc). > and chance to get more log messages because the insanity propagates. > > > > Now let's get to the other points: > > 2) Since this is not the default, then I do not understand why you are > so concerned. > > 3) Can you explain to me why it is so upsetting to you that someone > might be able to use this functionality? > > 4) *puts on flame retardant suit* ... Linux has had this for over a > decade and it's allowed them to find bugs in different ways. Mind you, > in Linux it was the default. > > 5) Adrian and I have both stated that we need this sort of functionality > to avoid superfluous panics in our work environments while still getting > bug feedback. > > Can we now please stop arguing over a non-default option that will help > some vendors report bugs to the project? > > Thank you, > -Alfred >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C91B32.4080904>