From owner-svn-src-all@FreeBSD.ORG Thu Dec 13 00:03:02 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A794DEF; Thu, 13 Dec 2012 00:03:02 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECF88FC0C; Thu, 13 Dec 2012 00:03:01 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so956853pbc.13 for ; Wed, 12 Dec 2012 16:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rUkkDS+u9T7qLpp5uJ5SoOT/90sisZr58CIKe88eUbw=; b=Hd3O7Psay78hbAr1h7RcqT/kDV4pQ3vzCp/C65onL3sGr99TZxc7rT8iQwhl0pxhkK ZiLL7lXY+bmT3zRr6OoNko76J74V3o/3Orhbjq20gF6h1KKpIelfyYiBFVYafrNiA566 y7vLqIoAZyjsc0m3PCeWkpcS5Upy45XOjy8NbLJvp5bAMfWgfXTiG50VGD+dZycqVny4 6nadsgp+bMKggdamZSrgixJGXbksHg333C6shIAx6h4/urzTv1KExmY93u9mLdqZ4DBT vRxjpgQbtTC3gEcxkqSnDnVQHgA9d9Cga+TacZHIJu9U990bdTEfCVvMxmqkPTad9ls2 dwNg== Received: by 10.66.82.230 with SMTP id l6mr1009565pay.12.1355356980857; Wed, 12 Dec 2012 16:03:00 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id l5sm102578paz.14.2012.12.12.16.02.59 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 16:03:00 -0800 (PST) Sender: Navdeep Parhar Message-ID: <50C91B32.4080904@FreeBSD.org> Date: Wed, 12 Dec 2012 16:02:58 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> <50C90567.8080406@FreeBSD.org> <50C909BD.9090709@mu.org> In-Reply-To: <50C909BD.9090709@mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, Alfred Perlstein , Andriy Gapon , svn-src-head@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:03:02 -0000 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 >