Date: Sat, 22 Mar 2014 12:13:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Andrew Turner <andrew@fubar.geek.nz>, svn-src-head@FreeBSD.org, Ruslan Bukin <br@FreeBSD.org>, John-Mark Gurney <jmg@funkthat.com> Subject: Re: svn commit: r263424 - head/sys/arm/conf Message-ID: <4112C2A8-2658-4962-A247-6E12257BC4F5@gmail.com> In-Reply-To: <1395494755.81853.38.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 22, 2014, at 7:25 AM, Ian Lepore <ian@FreeBSD.org> 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 <br@FreeBSD.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4112C2A8-2658-4962-A247-6E12257BC4F5>