"Next Generation" kernel configuration?
cpressey at catseye.mine.nu
Thu Jul 22 18:31:50 PDT 2004
On Tue, 20 Jul 2004 19:39:31 -0500 (CDT)
"Conrad J. Sabatier" <conrads at cox.net> wrote:
> Just musing on an idea here:
> I've been thinking for a while now about trying to write a tool to
> make kernel configuration easier, sort of a "make config" (as in
> ports) for the kernel, similar to what's available on some of the
> Linux distros.
> Ideally, such a tool would be capable of automatically adapting itself
> to handle and present as choices, in an orderly and logical fashion,
> whatever devices, options, etc. were currently available, as defined
> by the files in /sys/conf et al.
I gave this a brief shot on DragonFly with not much luck, but maybe some
insight - here's my experience.
The kernel config file should probably be replaced by a Makefile.
This way, the user can say something like:
MYKERNEL: device_i_want another_device_i_want ...
And of course somewhere else (probably in an included Makefile) the
dependencies would be specified a la
So, you'd never get a "doomed" kernel config that starts compiling but
chokes halfway through the build, because any needed devices would be
brought in automatically.
That's the easy part. The hard part is discovering the dependencies.
If you want to discover them automatically by looking through the kernel
source code files - all I can say is, good luck! You'll either need a
really, really smart relation-mining program, or more disciplined source
code organization, or both.
Alternatively, you could ascertain a set of dependencies manually
(many of them are noted in GENERIC, LINT, NOTES, etc,) but then you'd
also have to maintain that set when they change in the future. I'm not
so sure that's much of a drawback (since currently src/sys/conf/files
has to undergo that sort of maintenance anyway,) but it's less big of a
win than having it all nicely, automatically generated from the inherent
structure of the kernel.
> The major hurdle to overcome, it appears to me, is that the scheme
> currently employed to describe the available devices, options, etc.
> does not lend itself very easily at all to any kind of automatic
> parsing or other manipulations. Determining dependencies between
> components programmatically, for one thing, seems well near
Precisely the conclusion I came to as well.
More information about the freebsd-hackers