"Next Generation" kernel configuration?
max at love2party.net
Tue Jul 20 18:29:39 PDT 2004
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
Size: 187 bytes
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040721/0aa5e7ad/attachment.bin
More information about the freebsd-hackers