svn commit: r184193 - in head/sys: arm/conf conf
John Baldwin
jhb at freebsd.org
Mon Oct 27 16:03:19 UTC 2008
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'.
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.
--
John Baldwin
More information about the svn-src-head
mailing list