Date: Thu, 11 Dec 1997 01:34:07 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Jonathan Mini <j_mini@efn.org> Cc: The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <25819.881832847@time.cdrom.com> In-Reply-To: Your message of "Wed, 10 Dec 1997 23:49:09 PST." <19971210234909.29178@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>Ok. I was shooting for a 'minumum work' approach, and then once I got people
>used to the GUI I was going to be radical and start talking about replacing it
>with the new config junk. But, you're one step ahead of me.
Bite all of the bullet at once on this issue, I say! :-)
> We need to do this in three stages then :
> 1) decide what types of "configurability" we want to allow the config
> utility to handle. compile-time options, compiled-in device, managing
> LKMs (for now, I hope to see the kld code replace it) and other types
> of kernel behavior would be a good idea too.
> Plausably, we could extend this to cover any sort of system
> configuration, but whether we want to do that is what we'd talk about
> in this stage.
I think the above has actually been covered in some detail in this
mailing list over the last 3 or 4 other times this topic has come up,
but my own memory is faint on the details. Perhaps those previously
involved in raising this issue (was one of them Mike Smith, my memory
seems to tell me? And Terry?) would be willing to provide a summary
of the state of affairs last we left it, but from what I recall it
was basically agreed that:
o You should be able to specify just about any parameter with
one orthgonal scheme for picking defaults, specific values or
allowable ranges of values.
o You should be able to specify whether a device is optional,
mandatory, present-but-disabled, etc.
o Proper device sub-configuration support should replace the
bit-twiddling of flags.
o It should be possible to group devices by class so that if
the user selects "ahc0" as an option in some GUI, for example,
the interface can know to ask for the appropriate sd0/cd0/st0
device sub-configuration information. Dependencies would also
be handled similarly ("can't have *that* without *this*").
o It should be possible to associate documentation strings and/or URLs
with device entries so that they can actually be described to the
user.
o The new configuration format should still be ASCII and editable
by Mere Humans(tm), just in a format which is much more easily
machine-parsed.
And that's about all I can remember. I'm sure this will jog the
memories of others, though. :)
> 2) Once we have what we want to classify in our database defined, we
> should decide on a database method to store it. Most likely, due to
> extendability, a relational database will be the product of this stage.
> The exact format would be the issue under debate here.
Eek! See my comments about the ASCII part. I do remember people
being fairly adamant about this part, so you might want to capitulate
early and save valuable time. :-)
> 3) Then I get to actually write the database-handling code, and the
> GUI to deal with it. If you don't mind, I indent to not use
> libdialog. :)
If you'd said that you were, I'd have felt it my duty to recommend
strongly against it. :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25819.881832847>