Re: "Next Generation" kernel configuration?

From: Max Laier (max_at_love2party.net)
Date: 07/21/04

  • Next message: Conrad J. Sabatier: "Re: "Next Generation" kernel configuration?" 
    To: freebsd-hackers@freebsd.org
Date: Wed, 21 Jul 2004 03:27:22 +0200

    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@freebsd.org
\ /  Max Laier				| ICQ #67774661
 X   http://pf4freebsd.love2party.net/	| mlaier@EFnet
/ \  ASCII Ribbon Campaign		| Against HTML Mail and News

  • Next message: Conrad J. Sabatier: "Re: "Next Generation" kernel configuration?"

    Relevant Pages

    • "Next Generation" kernel configuration?
      ... with its explicit declarations of dependencies, ... given to doing something similar with kernel configuration files? ... current system of kernel configuration files would be required. ...
      (freebsd-hackers)
    • Re: "Next Generation" kernel configuration?
      ... > the kernel, similar to what's available on some of the Linux distros. ... > with its explicit declarations of dependencies, ... > current system of kernel configuration files would be required. ...
      (freebsd-hackers)
    • Re: local mail problem after FC4->FC5 upgrade
      ... All the machines on the network are using NIS for user information. ... This says that a spam daemon exited, then the email was delivered to root. ... changed any of the sendmail configuration files. ... If an old config file was overwritten, it could potentially cause all kinds of havoc on a custom installation. ...
      (comp.mail.misc)
    • Re: Best way to store config or preferences in a multi-platform way.
      ... In contrast to many other areas of software, configuration files needn't ... rest of the world uses config format X, you can safely stick with config ... Similar apps might want to have a feature like "import settings" from ...
      (comp.lang.python)
    • Re: /etc path: Can I hard code?
      ... And do not put your configuration files in /etc ... ... // so now you can synthesize a path top the config files. ... char temp; // LOL ... FILE *fptr; ...
      (comp.os.linux.development.apps)