From owner-svn-src-head@FreeBSD.ORG Mon Dec 17 21:47:38 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A80EB1DA; Mon, 17 Dec 2012 21:47:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 61C8F8FC17; Mon, 17 Dec 2012 21:47:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA29540; Mon, 17 Dec 2012 23:47:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TkiX4-0005o1-E3; Mon, 17 Dec 2012 23:47:30 +0200 Message-ID: <50CF92F0.5020904@FreeBSD.org> Date: Mon, 17 Dec 2012 23:47:28 +0200 From: Andriy Gapon 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> <50CBC285.7060307@mu.org> <20121215161414.V1029@besplex.bde.org> <201212171439.27297.jhb@freebsd.org> <50CF8CE7.4020906@mu.org> In-Reply-To: <50CF8CE7.4020906@mu.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Dec 2012 22:10:43 +0000 Cc: Adrian Chadd , src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, Alfred Perlstein , Gleb Smirnoff , Robert Watson , Navdeep Parhar , Bruce Evans , svn-src-head@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:47:38 -0000 on 17/12/2012 23:21 Alfred Perlstein said the following: > This is hard to explain to a customer. > > customer: "So we ran your debug image and got you a panic, here is the > information. So can you tell us what is the problem?" > alfred: "well that is due to XXX other thing that is broken, thanks for helping > us resolve that unrelated problem!" > customer: "i hate you" > alfred: "get in line." But you see, the following is still illogical _to me_. If one believes that all KASSERTs are bogus then one should compile them out and just forget about them. If one believes that at least some KASSERTs are such that the execution should not continue after them, then one should enable all of them and panic on all of them (better safe than sorry). If one is not satisfied with the above choices, then one should meticulously go over all (or at least some) of KASSERTs and make a decision which KASSERTs are bogus, which are true and which should be turned into something else (error checking, warnings, etc). The proposed solution simultaneously enables all KASSERTs, as if all of them were true, and doesn't panic on any KASSERT, as if neither of them is fatal (i.e. they all are bogus to one degree and another). P.S. I am not talking about the status quo because the status quo would be maintained even without the changes in question. -- Andriy Gapon