cvs commit: src/sys/i386/conf DEFAULTS GENERIC

[John Baldwin]

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'
> devices.

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 
off.

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