From owner-svn-src-all@FreeBSD.ORG Sun Dec 16 08:06:10 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 2E843719; Sun, 16 Dec 2012 08:06:10 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 068828FC0C; Sun, 16 Dec 2012 08:06:09 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 780E11A3C1C; Sun, 16 Dec 2012 00:06:08 -0800 (PST) Message-ID: <50CD80F0.6000203@mu.org> Date: Sun, 16 Dec 2012 00:06:08 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon 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> <50C91B32.4080904@FreeBSD.org> <20121215205202.GF1411@garage.freebsd.pl> <20121216040717.GG35245@server.rulingia.com> <1355634037.1198.115.camel@revolution.hippie.lan> <50CD7C1D.3020108@FreeBSD.org> In-Reply-To: <50CD7C1D.3020108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore , src-committers@FreeBSD.org, Peter Wemm , svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, Peter Jeremy 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: Sun, 16 Dec 2012 08:06:10 -0000 On 12/15/12 11:45 PM, Andriy Gapon wrote: > on 16/12/2012 07:00 Ian Lepore said the following: >> The question here isn't whether aborting or continuing beyond that point >> is a good idea. Some developer already made that choice by coding a >> KASSERT() instead of a panic(). The developer decided that a production >> machine should try to keep running at that point. > Please don't perpetuate this argument. The point of KASSERT is not that the > developer intended that the system should try to keep running in production. > The point is that (1) the KASSERT should not be hit in production as was > established in testing *and* (2) having all KASSERTs enabled in production is > too expensive. That's all. > I don't understand, we have a few partners running KASSERT enabled kernels. Depending on workload our machines can have enough CPU free for this. -Alfred