svn commit: r263424 - head/sys/arm/conf

[Warner Losh]

On Mar 22, 2014, at 7:25 AM, Ian Lepore <ian at 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 at FreeBSD.org> wrote:
>>>> 
>>>>> Author: br
>>>>> Date: Thu Mar 20 17:01:21 2014
>>>>> New Revision: 263424
>>>>> URL: http://svnweb.freebsd.org/changeset/base/263424
>>>>> 
>>>>> Log:
>>>>>  Disable debugging by default.
>>>> 
>>>> 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.
>> 
>> I agree...  HEAD needs these to make sure they are production ready...
>> 
>>> 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.
>> 
>> I wouldn't be tracking down an AVILA bug if it wasn't for INVARIANTS..
>> 
>> Also, your complaint is solely about WITNESS not the other ones...
>> 
>> 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...
>> 
>> If you're using HEAD for performance, it's easy to turn these off..
>> 
> 
> 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’s 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’/^options.*WITNESS/s=^=#=/‘

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’s a separate problem. DEFAULTS isn’t 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’s 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’t 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’d have a lot of
effort to something that’s crazy silly in a different way than what we have now.

Warner