From owner-svn-src-head@FreeBSD.ORG Sun Dec 16 17:23:15 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 D1010105; Sun, 16 Dec 2012 17:23:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF7D08FC12; Sun, 16 Dec 2012 17:23:14 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2370653wey.13 for ; Sun, 16 Dec 2012 09:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qf/CrXwViehZBv5u242Rd/XOPBQ1xH9u3Vbw87pK0ro=; b=eezZGz36FBJYE9+Mr7kfp8eDQ0ixsO3/5Bqx03BoYpYDADfxWEvHsigq/4b2yadO/C y815LzGo3eBi/QPKZnyJ6hmfMOzjcbBcVb+13MhGfdwMnmwu479E498RSqdgvrPFzwMQ cY8R3MC9D1tJavKodR4w4XCEYmHJJB8MjTV0rlvWK9tFQ9WG8TVmpNwBdmUAHHz+NMDx QeEJZbYxMuHjlKvMCgoDveI6mymNJ+KmLTpv5FWLO35r2JKEX6gfsKxe+m3Ey+rI/JXQ uItRka5YVOPAqXuQGuIWf2OPBG0JahmlTbgIypZaD6ewXsIvZkjpVJNiHmQt6xQ4N1zU ZLiQ== MIME-Version: 1.0 Received: by 10.180.102.234 with SMTP id fr10mr11621007wib.17.1355678593781; Sun, 16 Dec 2012 09:23:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 16 Dec 2012 09:23:13 -0800 (PST) In-Reply-To: <50CD7C1D.3020108@FreeBSD.org> 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> Date: Sun, 16 Dec 2012 09:23:13 -0800 X-Google-Sender-Auth: 0jKe4sI3oSJS00mCcwnVTOzzzMM Message-ID: Subject: Re: svn commit: r244112 - head/sys/kern From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 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-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 17:23:15 -0000 On 15 December 2012 23:45, 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. You can't possibly believe that once the kernel is in production, "testing" stops. That's why Alfred and I want to mak KASSERT() optionally just print that it happened and maybe add some further information, then continue. It doesn't change the status quo with the default, GENERIC "production" kernel. It still crashes where it would normally crash (timing bugs otherwise.) It still won't crash where it wouldn't trigger a kassert. A shipping, production kernel doesn't have KASSERT enabled. You may assert "assertions are supposed to crash", yet we ship with assertions disabled. Please, tell the software engineers here what you think that implies about what we think about those assertions. Let me give you a hint - if you ship with them disabled, they don't get run. So obviously we don't think there's a big enough problem to cause any real issues. Now, this may not be the case at all - in which case, those shouldn't be disabled in production kernels, for all the reasons everyone above has said. Yet, they're disabled. The status quo _does not change_ by default. Adrian