"Next Generation" kernel configuration?

[Max Laier]

On Wednesday 21 July 2004 03:03, Brooks Davis wrote:
> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier 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.
> >
> > 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 impossible.
> > The NOTES files, in their current form, make even finding the comment
> > associated with a particular option or device extremely difficult, if
> > not impossible.
> >
> > Has this ever come up for discussion before?  Now that we have rcNG,
> > with its explicit declarations of dependencies, has any thought been
> > given to doing something similar with kernel configuration files?
> > Something still human-readable, yet more orderly and systematic, easier
> > for a machine to interpret, present and verify?
>
> There have been previous discussions.  They should be visiable in the
> archives if you can find the magic search strings.
>
> > A dependable tool offering a menu-driven means of configuring the
> > kernel, ensuring proper config file syntax, dependency handling,
> > prevention of incompatible options, etc. -- as well as online
> > documentation, advice, suggestions and warnings, plus perhaps a nice
> > set of default selections -- would be a very nice addition to the
> > system.  But to bring it about, obviously a major reworking of the
> > current system of kernel configuration files would be required.
>
> You can have my simple flat file kernel config when you pry it from my
> cold, dead hands and I know a number of other develoeprs share this
> viewpoint.  All my experiences with the linux visual kernel config tool
> have been annoying and I've got friends with more expierence with it
> that have much less kind things to say.

Add me to the list. And this realates to sys/conf/* as well (respondig to the 
re-reply). Especially developers prefer *clean*, *simple* config files and I 
(personally) would really really hate to twiddle with some insane XML just to 
add something to the build!

> That said, so long as it doesn't impose too much developer burden,
> an improved set of backend files that did a better job of handling
> dependencies and knew which options where relevent given the configured
> set of devices could be useful.

http://www.freebsd.org/releases/5.3R/todo.html has a "Desired features"-item 
saying: "Revised kld build infrastructure", which will pretty much interfere 
with this. You might want to contact with the current owner (peter@) and hear 
what he has to say. Other than that, I'd welcome a somewhat enriched config 
environment as long as it is done reasonable and makes the job easier! And 
please: NO XML!

> There is a valid question of what a depenency means.  For instance, you
> can't really have IP networking without lo(4) (there's a null pointer
> derefrence if you try), but since you can load it as a module, should
> you have to compile it in?

There should be levels of dependencies ... i.e. the TBD config-tool would 
(strongly) suggest that you build-in lo(4) into an "options INET" kernel, but 
should not stop you to do else.

-- 
/"\  Best regards,			| mlaier at freebsd.org
\ /  Max Laier				| ICQ #67774661
 X   http://pf4freebsd.love2party.net/	| mlaier at EFnet
/ \  ASCII Ribbon Campaign		| Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040721/0aa5e7ad/attachment.bin