According to Bill Sommerfeld:

> > To me this spells configuration tables and dynamic kernel modules:
> > basically a load-time "config".  Largely, the mechanisms are in
> > place and exploring the possibility may be a worthwhile project.
> 
> Well, we already have sysctl controlling a bunch of other parameters
> like this..  I think the tendancy continues to be further towards "let
> the parameters be tweaked on the fly" rather than at kernel
> compile/link/boot time..
> 
Oh, I wasn't as much advocating dismissing sysctl, as streamlining the 
kernel load procedure with a bunch of easily edited configuration 
options.

Sure there are potential inconsistencies, but then a "vipw"-styled 
configuration editor could link sysctl to the permanent kernel 
configuration table as well.

By now we have a very pretty loader (pity it doesn't do multiboot - I'd 
love to use to switch to NT or Plan 9 at boot time :-) that could 
easily set the kernel environment, load a skeleton kernel (the 
read-only bit of the kernel) which in turn would load device drivers 
and set conditions as specified by the configuration file.

Ideally, the config table would be similar in scope to the existing 
facility, a scan would be limited to devices listed in the table, and 
the table trimmed to those found, then the kernel would discard all the 
device scan and possibly initialisation code (no, I haven't thought 
about PCMCIA/PC-Card or USB :-) and only hold in memory the active 
portions of the device drivers.

I'd go this route, had I all the time and ability required, but I'm 
very curious about all the facets I may have missed, not being much of 
an expert in the field.  By all means mail me privately, I'll summarise.

++L