Date: Thu, 11 Dec 1997 02:05:55 -0800 From: Jonathan Mini <j_mini@efn.org> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Jonathan Mini <j_mini@efn.org>, The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <19971211020555.60627@micron.mini.net> In-Reply-To: <25819.881832847@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 01:34:07AM -0800 References: <19971210234909.29178@micron.mini.net> <25819.881832847@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard <jkh@time.cdrom.com> stands accused of saying:
> > 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:
Somehow I'm not surprised. I'll assume that Terry'll comment somewhere along
the line, whether or not he was originally noisy about it. :)
(I know several jokes that start with "Terry walked into a bar with a Rabbi
and a Priest..", but that's not the point here... )
> 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.
Noted :
+ option classes of several types should be supported. An option would be
defined as anytihng that is settable during compile-time. This would mean
that items such as compiled-in devices, pseudo-devices, filesystems, etc,
as well as what we currenly call an "option" would be optionable.
+ each option class would have a series of named entires in a "template."
This template would define the kind of settings are allowed, required,
obsolete, etc. There would be multiple setting types, one for each kind of
C data type : one to represent a struct, an array, an integer, a valid
subrange of an integer or string, a string itself, a boolean, and a
a construct for flags comes to mind and wouldn't be hard to implement.
(A recursive data definition is implied here, thus easily attacking
structs, arrays, and subranges)
+ series of "database templates" would be possible, or built-in. Meaning
that two things are possible :
1) default settings can be noted in the same database as defines an
option, as well as a series of "common" (or possible) sets of settings.
As an example, see what I showed about the "settings" for COM1, COM2,
etc with sio.
2) The equivalent of a kernel configuration file can also act as a
tmeplate. merging several kernel config files would be fairly easy,
providing that conflicts can be resolved by a general rule. For
example, consider a site creating a "template" config file for their
system, and then applying "local" files to that template for each
machine's kernel. With this method, several custom kernels could be
compile in one batch, with simple generalization among them.
> o You should be able to specify whether a device is optional,
> mandatory, present-but-disabled, etc.
Noted :
+ all option classes can be tagged as requiring a certain set of options,
something like a boolean evaluation would be best (only ok when
(added(this) && added(that)) || added(theotherthing)) Obviously, the
classification of each option's settings would be a per-option-class, but
I would assume that things like the device option class would contain a
"present but disable" setting.
> o Proper device sub-configuration support should replace the
> bit-twiddling of flags.
Noted :
+ all options can contain more information than a simple #define, although
having an option _create_ a #define would certainly be possible. (it would
have to, otherwise detecting features enabled would be hell, and it would
break current code) Obviously, creation of a "setting" struct for that
device would be extremely possible.
This would most likely require rewriting user-config from scratch.
> 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*").
+ dependancies I talked about above, but having an option require a certain
logical expression to be true would handle this well.
+ Not only that, but the RESOURCES used by a device would be classified and
managed as well, so that the kernel config would know about possible
conflicts before compling the kernel. This would be handled by creating
classes of resources, in which a range or set of ranges could be allocated.
This same method would allow the handling of scsi disk hardwiring.
> 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.
+ I was assuming that there would be two calssifications of documentation
avialable about a specific option or option class :
1) internal documentation. This would be a string or set of strings
that is displayed under various contexts for an option. This provides
things like names, short one-line descriptions, etc.
2) external docuimentation. Something like a URL pointing to a web-page
or document handbook as well as a reference to a man-page would be
possible. I'm assuming that the CUI would be able to fire off the
appropriate reader to view this "on the fly."
> 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.
Of course. I would shoot anybody who said otherwise, and then bill the travel
costs to thier next-of-kin.
> 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. :-)
I meant the specific layout of the ASCII file that contains the
classification. I was assuming a relational database (contained in a text file)
because of it's flexibility, extendability, and the ability to "survive" across
multiple versions without modification.
--
Jonathan Mini Ingenious Productions
Software Development P.O. Box 5693,
Eugene, Or. 97405
"A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971211020555.60627>