svn commit: r184193 - in head/sys: arm/conf conf

[John Baldwin]

On Tuesday 28 October 2008 12:19:10 am M. Warner Losh wrote:
> In message: <200810271159.31843.jhb at freebsd.org>
>             John Baldwin <jhb at FreeBSD.org> writes:
> : On Friday 24 October 2008 06:47:40 pm Warner Losh wrote:
> : > From: John Baldwin <jhb at freebsd.org>
> : > Subject: Re: svn commit: r184193 - in head/sys: arm/conf conf
> : > Date: Fri, 24 Oct 2008 10:31:07 -0400
> : > 
> : > > On Friday 24 October 2008 09:27:03 am Alexey Dokuchaev wrote:
> : > > > On Fri, Oct 24, 2008 at 03:26:43AM +0200, Dag-Erling Sm??rgrav 
wrote:
> : > > > > Warner Losh <imp at bsdimp.com> writes:
> : > > > > > We already have a better mechanism for including config files.  
We
> : > > > > > should be using that instead of poluting another port with the
> : > > > > > DEFAULTS file.
> : > > > > 
> : > > > > Should we even have DEFAULTS files at all?  IMHO they just confuse
> : > > > > matters by introducing "stealth" options into your config.
> : > > > 
> : > > > I tend to second this.  I always try to get everything possible out 
of
> : > > > my kernel to modules, and thus was surprised to see io.ko and mem.ko
> : > > > fail to load because they were silently included into my custom 
kernel.
> : > > > 
> : > > > I understand that some things like 'device isa' and
> : > > > 'device npx' aren't really optional, but if something is useful to 
have,
> : > > > but can be loaded as a module, it belongs to GENERIC rather than
> : > > > DEFAULTS.  Killing the latter altogether and throwing a comment that
> : > > > says particular option or device is mandatory in GENERIC is probably
> : > > > even better (and more transparent).
> : > > 
> : > > The one thing I think DEFAULTS is useful for are replacing NO_FOO 
options 
> : with 
> : > > FOO options.  That is, if someone wants to turn a feature on by 
default, 
> : I'd 
> : > > rather them put 'options FOO' in DEFAULTS rather than rename all the 
> : > > #ifdef's,e tc. to '#ifndef NO_FOO'.
> : > 
> : > Wouldn't it be better to move to a system where we explicitly include
> : > std.i386 and have them all defined there?  We already encourage stuff
> : > like this with advice to include GENERIC with nodev...
> : 
> : I wouldn't mind a std.i386, and if we make config's include keyword fall 
back 
> : to 'sys/conf' for relative path name lookups if the lookup in '.' fails 
then 
> : you can even put those files in sys/conf with the still-clean syntax 
> : of 'include std.i386'.
> 
> Already works that way...
> 
> : However, I don't know about you, but I _never_ build a config by including 
> : GENERIC and then weeding stuff out.  Too much stuff to weed out.  Once I 
have 
> : a customized config for a machine I then include that in development 
branches 
> : to install kernels to different directories under /boot, etc.
> 
> Yea,  Well, I was thinking of std.firewire, et al.  Trouble is we'd
> then have to slice thing by bus (std.pccard, std.cardbus, std.pci,
> std.iic, std.usb) and by function (std.wireless, std.scsi, std.serial)
> which slices across different functional groups...
> 
> Warner
> 
> P.S.  Here's a diff of something we can do today...  This is just a
> quickie demo, not a proposed patch to the tree...  It also assumes
> that we have nocpu defined in config, which I haven't verified.

I wouldn't bother doing the CPU bits yet, I would just rename the existing 
DEFAULTS files and then remove the code from config(8) to auto-include 
DEFAULTS.  Then if you wanted to do further tweaks to std.<arch> you can do 
that later.

-- 
John Baldwin