Date: Fri, 31 Mar 1995 21:32:28 +0100 (BST) From: Doug Rabson <dfr@nlsys.demon.co.uk> To: Bakul Shah <bakul@netcom.com> Cc: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>, hackers@freefall.cdrom.com Subject: Re: Configuration database (was Re: Changed information for PR misc/278) Message-ID: <Pine.BSF.3.91.950331213002.1077C-100000@nlsys.demon.co.uk> In-Reply-To: <199503292133.NAA19430@netcom9.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.950331213002.1077C-100000>