From owner-svn-src-all@FreeBSD.ORG Wed Dec 12 22:33:44 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 EEC0BC60; Wed, 12 Dec 2012 22:33:43 +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 48C6C8FC12; Wed, 12 Dec 2012 22:33:42 +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 AAA07296; Thu, 13 Dec 2012 00:33:38 +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 1Tiury-000MRH-7Y; Thu, 13 Dec 2012 00:33:38 +0200 Message-ID: <50C90641.4030000@FreeBSD.org> Date: Thu, 13 Dec 2012 00:33:37 +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> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> <50C904B8.6000502@mu.org> In-Reply-To: <50C904B8.6000502@mu.org> X-Enigmail-Version: 1.4.6 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 , 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: Wed, 12 Dec 2012 22:33:44 -0000 on 13/12/2012 00:27 Alfred Perlstein said the following: > On 12/12/12 2:15 PM, Adrian Chadd wrote: >> On 12 December 2012 13:58, John Baldwin wrote: >> >> >>> (Note that the primary reason I know for people not running with INVARIANTS >>> enabled is not that they don't want panics, but that they don't want the >>> performance hit.) >> Well, it would be nice to be able to enable invariants on some >> shipping "debug" versions of images in order to gather more data >> without crashing the kernel. > Yes, two of my employers were more of "we want to get more debug metrics, we > have the spare cycles, but we can't deal with superfluous panics". > > It also allows us "non-architects" to slip in a debug image when we have spare > cpu without getting yelled at for "crashing the $foo". There is clearly something wrong with this sort of mentality. If you find instances where a developer put panic(9) (or KASSERT or etc) to mean "maybe here is a bug, let's just panic", then let's get those things fixed. But most of assertions in our code that are know to me really mean that a real bug has already occurred, that portions of kernel state are corrupted and there is no going back to a sane state, only going forward to corrupting more and more. -- Andriy Gapon