On Tuesday 28 October 2008 12:19:10 am M. Warner Losh wrote:
> In message: <email@example.com>
> John Baldwin <jhb@FreeBSD.org> writes:
> : On Friday 24 October 2008 06:47:40 pm Warner Losh wrote:
> : > From: John Baldwin <firstname.lastname@example.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
> : > > > > Warner Losh <email@example.com> writes:
> : > > > > > We already have a better mechanism for including config files.
> : > > > > > 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
> : > > > 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
> : > > >
> : > > > I understand that some things like 'device isa' and
> : > > > 'device npx' aren't really optional, but if something is useful to
> : > > > 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
> : with
> : > > FOO options. That is, if someone wants to turn a feature on by
> : 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
> : to 'sys/conf' for relative path name lookups if the lookup in '.' fails
> : 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
> : a customized config for a machine I then include that in development
> : 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...
> 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