From owner-freebsd-hackers Wed Mar 29 13:45:32 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA01787 for hackers-outgoing; Wed, 29 Mar 1995 13:45:32 -0800 Received: from netcom9.netcom.com (root@netcom9.netcom.com [192.100.81.119]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA01771 for ; Wed, 29 Mar 1995 13:45:22 -0800 Received: from localhost by netcom9.netcom.com (8.6.11/Netcom) id NAA19430; Wed, 29 Mar 1995 13:33:00 -0800 Message-Id: <199503292133.NAA19430@netcom9.netcom.com> To: Garrett Wollman cc: hackers@freefall.cdrom.com Subject: Configuration database (was Re: Changed information for PR misc/278) In-reply-to: Your message of "Wed, 29 Mar 1995 11:56:56 -0500" <9503291656.AA14584@halloran-eldar.lcs.mit.edu> Date: Wed, 29 Mar 95 13:32:53 -0800 From: Bakul Shah Sender: hackers-owner@FreeBSD.org Precedence: bulk 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.