From owner-svn-src-head@FreeBSD.ORG Sun Dec 16 07:45:51 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 A8CDE91; Sun, 16 Dec 2012 07:45:51 +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 8A07D8FC0A; Sun, 16 Dec 2012 07:45:50 +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 JAA12833; Sun, 16 Dec 2012 09:45:35 +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 1Tk8ul-0002jH-I7; Sun, 16 Dec 2012 09:45:35 +0200 Message-ID: <50CD7C1D.3020108@FreeBSD.org> Date: Sun, 16 Dec 2012 09:45:33 +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: Ian Lepore 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> In-Reply-To: <1355634037.1198.115.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Peter Jeremy , Peter Wemm 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: Sun, 16 Dec 2012 07:45:51 -0000 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. -- Andriy Gapon