Re: "Next Generation" kernel configuration?

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 07/21/04

  • Next message: Conrad J. Sabatier: "Re: "Next Generation" kernel configuration?" 
    Date: Tue, 20 Jul 2004 18:03:42 -0700
To: "Conrad J. Sabatier" <conrads@cox.net>

    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.

    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.

    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?

    -- Brooks 

    -- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

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

    Relevant Pages

    • Re: "Next Generation" kernel configuration?
      ... >> with its explicit declarations of dependencies, ... >> current system of kernel configuration files would be required. ... > You can have my simple flat file kernel config when you pry it from my ...
      (freebsd-hackers)
    • "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: [patch] drivers: wait for threaded probes between initcall levels
      ... I guess finer-grained initcall levels ... Maybe I'm just showing my ignorance about kernel linking here... ... My main concern are circular dependencies. ... "synchronisation object" against which dependers and dependees can register ...
      (Linux-Kernel)
    • Re: CFD: XMLification of NOTES
      ... objects that self-describe their dependencies. ... (Or at least embed .ko files into the kernel). ... a list of things to go in the static kernel and the generic modules ... For example, you can have a device driver with pci, isa, ...
      (freebsd-arch)
    • Re: CFD: XMLification of NOTES
      ... objects that self-describe their dependencies. ... (Or at least embed .ko files into the kernel). ... a list of things to go in the static kernel and the generic modules ... For example, you can have a device driver with pci, isa, ...
      (freebsd-arch)
    • Quantcast