Re: "Next Generation" kernel configuration?

From: Murray Taylor (murraytaylor_at_bytecraftsystems.com)
Date: 07/21/04

  • Next message: Joe Marcus Clarke: "Getting a fully-qualified path from a PID" 
    To: conrads@cox.net
Date: Wed, 21 Jul 2004 17:01:41 +1000

    On Wed, 2004-07-21 at 11:53, Conrad J. Sabatier wrote:
    > On 21-Jul-2004 Max Laier wrote:
    > > On Wednesday 21 July 2004 03:03, Brooks Davis wrote:
    > >> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
    > [snip]
    > >> > 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!
    >
    > Oh, agreed, definitely. Wasn't even thinking XML (yuck!). :-)
    >
    > Basically, I'm just thinking of a layout which, in the simplest,
    > cleanest manner possible, would allow a "make config"-like tool to
    > extract the information it needed, so options could be presented to
    > the user along with their descriptions, if so desired. I don't have a
    > clear-cut idea just yet of how this might be done, to be honest. :-)
    >
    > >> 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.
    >
    > Thanks for the pointer. I'll check into that.
    >
    > > 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!
    >
    > Cool. And not to worry. 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.
    >
    > Exactly. That's the sort of thing I had in mind.
    >
    > I realize this is a fairly large undertaking, and hearing that others
    > have already made attempts but have yet to produce anything makes me a
    > little uncertain about it all, but I do think it's something worth
    > exploring. And it'll keep me off the streets and out of trouble for a
    > good while, too. :-)
    >
    > If I manage to come up with anything reasonable, you'll hear about it
    > here.

    As an initial starting point for 'preloading' any menubased kernel
    configurator, could the file /var/run/dmesg.boot be usefully parsed as
    a list of 'this is what is actually installed in this box, what else do
    you want to add?" Of course any output developed on a run of the
    configurator would/could/should be scanned as well to include answers to
    the question.."What did I include last time?"

    0.02c
      

    -- 
Murray Taylor
Special Projects Engineer
---------------------------------
Bytecraft Systems & Entertainment
P: +61 3 8710 2555
F: +61 3 8710 2599
D: +61 3 9238 4275
M: +61 417 319 256
E: murraytaylor@bytecraftsystems.com
or visit us on the web
http://www.bytecraftsystems.com
http://www.bytecraftentertainment.com
---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material. 
E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------
****************************************************************
This Email has been scanned for Viruses by MailMarshal.
****************************************************************
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Joe Marcus Clarke: "Getting a fully-qualified path from a PID"