[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Configuration database (was Re: Changed information for PR misc/278)
From:       Doug Rabson <dfr () nlsys ! demon ! co ! uk>
Date:       1995-03-31 20:32:28
[Download RAW message or body]

On Wed, 29 Mar 1995, Bakul Shah wrote:

> 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?

Smells a lot like AIX ;-)

Seriously though, I quite liked AIX sys admin after I got used to that 
funny SMIT thing.  It had basically exactly this aproach of an OO 
database from which old-style configuration files were generated.

--
Doug Rabson				Mail:  dfr@nlsys.demon.co.uk
					Phone: +44 181 951 1891

[prev in list] [next in list] [prev in thread] [next in thread]