In message: <firstname.lastname@example.org>
John Baldwin <jhb@FreeBSD.org> writes:
: On Friday 24 October 2008 06:47:40 pm Warner Losh wrote:
: > From: John Baldwin <email@example.com>
: > 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 <firstname.lastname@example.org> 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
: > > FOO options. That is, if someone wants to turn a feature on by default,
: > > 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...
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.
--- conf/std.i386 (revision 0)
+++ conf/std.i386 (revision 0)
@@ -0,0 +1,33 @@
+# DEFAULTS -- Default kernel configuration file for FreeBSD/i386
+# $FreeBSD: head/sys/i386/conf/DEFAULTS 181776 2008-08-15 20:58:57Z kmacy $
+# Default CPU support
+# Bus support.
+# Floating point support.
+# Pseudo devices.
+device mem # Memory and kernel memory devices
+device io # I/O device
+# UART chips on this platform
+# Default partitioning schemes
+# enable support for native hardware
--- i386/conf/DEFAULTS (revision 184107)
+++ i386/conf/DEFAULTS (working copy)
@@ -1,28 +0,0 @@
-# DEFAULTS -- Default kernel configuration file for FreeBSD/i386
-# Bus support.
-# Floating point support.
-# Pseudo devices.
-device mem # Memory and kernel memory devices
-device io # I/O device
-# UART chips on this platform
-# Default partitioning schemes
-# enable support for native hardware
--- i386/conf/GENERIC (revision 184107)
+++ i386/conf/GENERIC (working copy)
@@ -18,9 +18,8 @@
# To statically compile in device wiring instead of /boot/device.hints