This is an old revision of the document!
New kernel configuration system
Wojciech A. Koszek
wkoszek@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/
Current kernel configuration system has its roots in
old BSD days. It's similar to sysinstall – it does
the job, but the FreeBSD world would be a bit better
with having different/better config(8).
The goal of the page is to list config(8) limitations
and problems hitting us in FreeBSD-9 times. This may be
a root of “config(8) suck less” project.
config(8) should:
- build all .c files just once, and use object files to create the kernel and modules
- right now we actually compile kernel twice–for the kernel and modules separately
- support dependencies
- right now when some option is missing, you'll get link time error - try to keep nice structure of
conf/files, since it's relatively easy to insert file there
- support out-of-tree module build - or at least be smart enough to let us to remove (or limit) src/sys/modules.. This seems to be just a hack-around the problem that
config(8)stinks pretty badly.
- DSL implemented: -
nooption nosomething- enable disable and other don't work well.
- be able to configure cross-arch kernels
configuration file/config(8) versioning
Lets forget about config(8) for now. Let config2(8) be a new configuration tool.
We meet a case where:
- newconfig(8)-v1 operates on GENERIC-v1 and generates only Makefile for kernel and modules.
- BadCommiter brings “option TWICE_AS_FAST”, which makes your kernel compile and work twice as fast – it is based on kernel and newconfig(8) new features, new file generation, new parsing etc..
- newconfig(8) gets its version number bumped and becomes newconfig(8)-v2. TOGETHER with newconfig(8), configuration file becomes GENERIC-v2. Both Stuff gets commited.
There are 4 cases:
| newconfig version | config file version | case number |
|---|---|---|
| 1 | 1 | A |
| 1 | 2 | B |
| 2 | 1 | C |
| 2 | 2 | D |
case A
Everything works – user didn't update his /usr/src after BadCommiter's
commit; newconfig(8) and GENERIC versions match. User doesn't get new features.
case B
User tries to use old newconfig(8) with new GENERIC.
Version between the tool and a file doesn't match. User could get
an error message about a need to recompile newconfig(8) or a
chance to ignore the kernel option entirely.
case C
This is “OK” case – new tool should be able to process old configuration
files. Have we ever tried to remove config(8) functionality, so that this
problem should be addressed as well?
case D
User updates his /usr/src; he reads UPDATING and sees a message about newconfig(8) changes. He updates newconfig(8) and reconfigures his kernel with new options.
This case is 'the correct one', but is problematic for developers, who tend to keep dozens of src/sys/… tree around, since newconfig(8) has to be updated for them in order to get their kernels to compile.