From owner-svn-src-all@FreeBSD.ORG Thu Dec 13 00:53:49 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 59F2F10F; Thu, 13 Dec 2012 00:53:49 +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 32F848FC0C; Thu, 13 Dec 2012 00:53:49 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id B78A81A3C1B; Wed, 12 Dec 2012 16:53:48 -0800 (PST) Message-ID: <50C9271C.70803@mu.org> Date: Wed, 12 Dec 2012 16:53:48 -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: Navdeep Parhar 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> <50C91CD3.7030900@mu.org> <50C9206D.6080502@FreeBSD.org> In-Reply-To: <50C9206D.6080502@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, Alfred Perlstein , Andriy Gapon , 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: Thu, 13 Dec 2012 00:53:49 -0000 On 12/12/12 4:25 PM, Navdeep Parhar wrote: > On 12/12/12 16:09, Alfred Perlstein wrote: > >> What do you think happens to a FreeBSD kernel when INVARIANTS is >> compiled in and it trips an assertion after my change? > I know the new knob has sane defaults. My point was that invariants > should be considered inviolable. A knob that allows for > it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their > meaning, so it may have been better to introduce a new macro for the > kind of tests you had in mind. I would use it too instead of the if > (!foo) kdb_backtrace() that I often resort to for conditions that I'm > not sure about. > The problem again is that not all the KASSERTS are inviolable, if you want to do a project to split them, then please do, it would really be helpful, as for now, they are a mis-mash of death/warnings and there are at least three vendors who approve of this as well as 3 long term committers that approved my change (not including Adrian). I'll be completely honest, I struggled very much with this KASSERT problem at a previous employer, and the second that Adrian brought up the idea of "optional panic" I was kicking myself so hard because the solution to so many problems suddenly jumped out at me. I will assure you that taking a stand on this one issue has the following problems: 1) Makes it harder for at LEAST three vendors to shake out and report bugs back to the project. 2) Makes it more likely that someone who has useful (to some, but not all) patches to keep them private to avoid such arguments. Anyhow after all this back and forth on changes that really do not effect anyone, ie defaults stay the same, it really has me questioning the sanity of contributing and/or taking the time to give this sort of thing to the project. It really seems like people are getting very bent out of shape over minor enhancements that offer flexibility. Like what if I do gzipp'd kernel dumps next? (on my todo list) How many people will complain that "gzip is too dangerous in kernel context foo foo!!!!" Not sure, I guess I'll find out? -Alfred