cvs commit: src/sys/i386/conf DEFAULTS GENERIC
jhb at freebsd.org
Mon Oct 31 08:43:05 PST 2005
On Sunday 30 October 2005 01:21 am, David O'Brien wrote:
> On Thu, Oct 27, 2005 at 05:34:35PM +0000, John Baldwin wrote:
> > jhb 2005-10-27 17:34:35 UTC
> > FreeBSD src repository
> > Modified files:
> > sys/i386/conf GENERIC
> > Added files:
> > sys/i386/conf DEFAULTS
> > Log:
> > Create a default kernel config for i386 and move 'device isa' and
> > 'device npx' (both of which aren't really optional right now) and
> > 'device io' and 'device mem' (to preserve POLA for 4.x users upgrading
> > to 6.0) from GENERIC into DEFAULTS.
> I may be missing something. I don't quite follow the benefit of the new
> 'DEFAULTS' file. I'm also curious why we don't explicitly 'include'
> DEFAULTS in GENERIC vs. the new automagic include feature.
We can now make more things optional without breaking POLA for existing users.
Imagine if atpic became optional on i386. Folks who didn't update their i386
kernel configs would all break. With DEFAULTS, I can make it optional
without breaking anyone's kernel configs, and the 3 people that want it off
can use 'nodevice atpic'.
> I wonder if someone might trip over this not realizing everything that
> winds up in their config file. I for one have been using io.ko and
> mem.ko after coping GENERIC to FOO and removing the 'io' and 'mem'
It was considered for the io/mem case that the set of people doing what you
are doing is far smaller than the set of people moving directly from 4.x to
6.x who might miss adding the new options and end up with headaches. I don't
think very much at all should be in DEFAULTS, just stuff that really should
be enabled for nearly everyone and that one should explicitly go and turn
To answer other questions: no, INCLUDE_CONFIG_FILE will not handle DEFAULTS at
all. Consider DEFAULTS as part of the system config like sys/conf/files.
The other alternative thrown around was to use things like 'dev/mem/mem.c
default mem' to make that file default to on and you had to use 'nodevice
mem' to turn it off. That is a system setting much like the fact that we
include mutexes in the kernel by default. :) We don't dump the list of all
the files that were marked 'standard' when we do INCLUDE_CONFIG_FILE.
DEFAULTS is a less error-prone way of achieving things that are on by default
than 'dev/mem/mem.c default mem' since the latter can result in interesting
edge cases where what if one file from a module is default and the other
optional? DEFAULTS lets you turn things on at the device/option granularity
rather than file-level granularity. To my mind, things that should be in
DEFAULTS are things that only a few people might want to trim out for space
reasons (nanobsd), etc. For example, when I backported acpi to 4.x, I didn't
maek pmtimer optional, I made it standard instead. To be honest, I can't
think of any reason other than paranoid space savings to have pmtimer
optional, and I think that is another possible candidate for DEFAULTS.
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the cvs-all