From owner-svn-src-all@FreeBSD.ORG Sat Mar 22 18:21:04 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B134B9C0 for ; Sat, 22 Mar 2014 18:21:04 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7721890E for ; Sat, 22 Mar 2014 18:21:04 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so3847834iec.37 for ; Sat, 22 Mar 2014 11:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=RGq86dMqdJzrO9QUrySEl/w8kxuXC0N8QsaxgxNveTc=; b=MOKqZSoH/RcRRrfM89gEz1sSQlEyxzU9YmhS/LZa407I8QZDhcltdHqt2nQB+yRGBF gVLB/Lh3SyKdm142CCjcOps/owged2cIdCHxjbR18sGAg61WOdZl7EGQJaXsV1L5XsJh PLeEnGX++rOvVAj5ZdqJ35tcngQcxwcwwESoI1I/jAsPOBm6OQUto3uPj+PAEavBIcu0 oApHYKJysinxNSmtOGJDyS7/xFBTxRTNOD+vFvd6u/ayRSuJFmdUHUfluwIAfUsm2Qbq tZk/EBoH6eOHxKu/w7QInxCSql/KUIXDUtPiTyN4t9vASy4tdBKkRpCYRiJaig1d77hI G0rA== X-Gm-Message-State: ALoCoQmto5mo9BGMmJy8pDShcXDBR3VCa1UfQrsv2/+9knd/2dTBq5u2ODUsrfK9TyOE+l4NDAwo X-Received: by 10.43.79.66 with SMTP id zp2mr1347409icb.76.1395512008176; Sat, 22 Mar 2014 11:13:28 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id c10sm11590803igj.17.2014.03.22.11.13.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Mar 2014 11:13:27 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r263424 - head/sys/arm/conf From: Warner Losh In-Reply-To: <1395494755.81853.38.camel@revolution.hippie.lan> Date: Sat, 22 Mar 2014 12:13:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4112C2A8-2658-4962-A247-6E12257BC4F5@gmail.com> References: <201403201701.s2KH1L84024044@svn.freebsd.org> <20140321094316.76ccf459@bender.Home> <1395412070.81853.8.camel@revolution.hippie.lan> <20140321190402.GT32089@funkthat.com> <1395494755.81853.38.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Andrew Turner , svn-src-head@FreeBSD.org, Ruslan Bukin , John-Mark Gurney X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 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: Sat, 22 Mar 2014 18:21:04 -0000 On Mar 22, 2014, at 7:25 AM, Ian Lepore wrote: > On Fri, 2014-03-21 at 12:04 -0700, John-Mark Gurney wrote: >> Ian Lepore wrote this message on Fri, Mar 21, 2014 at 08:27 -0600: >>> On Fri, 2014-03-21 at 09:43 +0000, Andrew Turner wrote: >>>> On Thu, 20 Mar 2014 17:01:21 +0000 (UTC) >>>> Ruslan Bukin wrote: >>>>=20 >>>>> Author: br >>>>> Date: Thu Mar 20 17:01:21 2014 >>>>> New Revision: 263424 >>>>> URL: http://svnweb.freebsd.org/changeset/base/263424 >>>>>=20 >>>>> Log: >>>>> Disable debugging by default. >>>>=20 >>>> I don't like this on head. I have found a number of issues that = were >>>> hidden because the kernel config most people were using for = development >>>> had WITNESS, INVARIANTS and DIAGNOSTIC disabled. >>=20 >> I agree... HEAD needs these to make sure they are production = ready... >>=20 >>> I disagree. Witness is essentially useless anymore, because there = are >>> so many known LORs that nobody cares about when you report them that = all >>> it does is spews noise. Maybe it's useful when you're looking for a >>> particular problem, but leaving it on all the time has just lost its >>> value. >>=20 >> I wouldn't be tracking down an AVILA bug if it wasn't for = INVARIANTS.. >>=20 >> Also, your complaint is solely about WITNESS not the other ones... >>=20 >> Considering how many people are writing new drivers for ARM, and = might >> be introducing locking issues w/ those new drivers, WITNESS should be >> included, plus, if you disable INVARIANTS, it means that all the >> lock assert functions will be turned off, and we might miss an odd >> calling stack which doesn't hold a lock or something... >>=20 >> If you're using HEAD for performance, it's easy to turn these off.. >>=20 >=20 > My complaint is only about witness. WItness is actually useful... > But... about being easy to turn off... how do they get turned off on > non-head branches? Does re@ really have to go grovel through 77 = config > files turning off diagnostic options? Do we have to handle that > difference when merging things to stable branches? It=92s done with a sed script, iirc. Writing the one liner took me just = a few minutes: dir sys/*/conf/[A-Z]* | grep -v NOTES | grep -v hints | grep -v Makefile = | grep -v DEFAULTS | xargs sed -i.bak -e=92/^options.*WITNESS/s=3D^=3D#=3D= /=91 would do the trick (for each option, add a clause at the end). But it is = uglier than it needs to be :) > Last time I tried to put something into arm/conf/DEFAULTS I got my = hand > slapped, but... putting the diagnostic options in there on head and = not > on stable branches would make the "touch 77 config files" problem go > away. That=92s a separate problem. DEFAULTS isn=92t the solution to that = problem. The solution lies either in a revamp of the config system, or people = dropping the resistance to std.foo that we partially do in arm, but should fully do = in arm (and elsewhere too). That system has worked well for NetBSD and there=92s no = reason for us not to go that route. However, efforts in this area quickly = degrade into the bikeshed from hell, and we get silly things like FOO.common instead = that more properly would be part of an expanded std.foo system. Of course, = our config system isn=92t quite up for the std.foo for everything, since = conditional includes and/or conditionals in general is an area where it is quite = weak, so when you expand it to a new axis other than board -> soc -> = soc-family -> core -> cpu it gets dicy (and most of the FOO.common stuff is for = that first step, while std.foo is done for almost all the rest). But honestly, the radical revamp is the proper path forward, since it = could also help us with the duplicate information for modules we have now, the massive duplication in config files and about a dozen kludges of varying degrees that are good enough for now, but showing signs of strain. = Putting the effort into the std.XXX system would help some, but we=92d have a = lot of effort to something that=92s crazy silly in a different way than what we = have now. Warner=