Date: Wed, 29 Mar 95 13:32:53 -0800 From: Bakul Shah <bakul@netcom.com> To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> Cc: hackers@freefall.cdrom.com Subject: Configuration database (was Re: Changed information for PR misc/278) Message-ID: <199503292133.NAA19430@netcom9.netcom.com> In-Reply-To: Your message of "Wed, 29 Mar 1995 11:56:56 -0500" <9503291656.AA14584@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard says:
> We've always just barreled along and never even really given
> the user the opportunity to easily deselect what might be an entirely
> gratuitous set of daemons..
> Sigh.. I think it must be said: Most of /etc is a mess, it always has
> been a mess and all I've ever seen other operating systems do with it
> is make it a more *convoluted* mess (SVR4 - gag me!). What's the
> cool, killer paradigm shift we're missing here? :-)
In two words: configuration database!
Garrett Wollman sez:
> As for configuration, I have had a dream occasionally that we could
> have a completely integrated, text-file-based, configuration database
> system with a different sort of naming concept.
I experimented with something like this in my Fortune
Systems days [in '83! Gawd, I feel old]. Here is how I
would do this today:
1. Describe configuration using a consistent syntax. Some
type of configuration objects may be hard wired but it
should be possible to add new object types using the
same syntax. Allow storing this information in a number
of places. See below for an example of such a syntax.
I have some code that handles a lot of it.
2. Provide a library to fetch/store whole objects or some
particular components. Tools using this library should
ignore object components they do not understand. This
makes the design open ended. [And allows you to store
stuff like font spec., image, audio file names etc. for
snazzy graphical interfaces].
3. init should be made to understand this syntax. Based on
what devices have been found, its current state and user
specified options in the config. database (CDB), it
starts up various things (in some sequence specified in
the CDB).
During bootstrap it should be possible to interactively
control this process for debugging purposes.
Probably a minimal backup CDB should be built in init to
allow progress even when the root FS is totally messed
up.
4. It is inevitable that some scripts will have to be run
-- we should use /bin/sh where it is best suited -- but
a lot of tests can be removed from the rc scripts.
Where such configuration tests are needed, they should
use a command that queries the CDB.
5. Convert a number of disparate databases that are using
their own peculiar syntax into this format. Converters
to old formats can be written to handle legacy
applications.
6. Have the kernel provide a device DB in a similar format
in the /kern filesystem or through some syscall.
[which reminds me, I'd also like to see the bootstrap
chatter from device drivers brought into some sort of
usable format and should only be printed optionally].
7. Tie-in the installed package database somehow. For some
packages we need to run scripts at bootstrap time (or
while going multiuser) and they should use the same
configuration mechanism as the base system.
Comments? Any interest, anyone?
-- bakul
Example of a syntax:
Today I would be happy with a LISP style syntax too but in
the version I did, I chose the familiar
keyword: value
syntax, with some extensions. The object value can be a
compound value with each component specified with its own
keyword: value pair. For example,
foo: {
bar: 42
baz: jaskl askdladj
}
I also allowed the dotted pair notation. Thus the above
object can also be specified as
foo.bar: 42
foo.baz: jaskl askdladj
If this record was in file /usr/gorp, externally you can
reference gorp.foo.bar or /usr/grop.foo.bar and get 42.
Later on I used the same syntax for storing my address book
(accessed via a card index program) and added some meta
objects to essentially define the type/prototype of an
object. I also expanded the value types where you can store
integers, reference to other objects or their components, a
list of values, etc.
The key thing to note is that this is a very general format
and can be parsed fairly quickly and easily. I have used
it for all sorts of things.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503292133.NAA19430>