From owner-freebsd-hackers Mon May 18 09:22:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06464 for freebsd-hackers-outgoing; Mon, 18 May 1998 09:22:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06446 for ; Mon, 18 May 1998 09:22:15 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id JAA27852; Mon, 18 May 1998 09:22:16 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Dan Janowski cc: freebsd-hackers@FreeBSD.ORG Subject: Re: system config database... In-reply-to: Your message of "Mon, 18 May 1998 00:42:42 EDT." Date: Mon, 18 May 1998 09:22:16 -0700 Message-ID: <27848.895508536@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've been putting brain power into > the issue of a configuration system for /etc. > I have done something along this path with > M4 for a similar purpose. > > Is M4 too weird to use for something of this > scope? No, I don't think so, though it's also pretty damn cryptic and I'd hope that any future standard for /etc would emphasise both flexibility AND ease of use since the average skill level of the Unix population is only steadily declining. M4 is powerful, few would deny that, but it's also cryptic as hell. If I had my druthers, there would be a single text file in /etc which stored all the configuration data for system startup. People wouldn't (generally) be expected to edit it directly but rather use one or more browsing tools for displaying and editing each "startup object" in a friendlier form, that perhaps looking something like this: name: amd desc: The Auto Mount Daemon for NFS filesystems. enabled: no class: net order: 9 requires: is_enabled nfs_client && is_enabled network v_exec: amd v_flags: -a /net -c 1800 -k i386 -d ${domain} -l syslog /host /etc/amd.map command: ${v_exec} ${v_flags} The attribute names are somewhat contrived, but basically you want each startup entity to be something which describes itself (thus eliminating the grotty in-line comments in /etc/rc.conf) and gives you sufficient hints about when to invoke it in the startup sequence (the class and order attrs). Everything which is ``enabled'' and matches its requirements check, something which could just be a line of sh(1) using a bunch of handy provided shell functions like ``is_enabled'' to prevent its becoming rapidly unreadable, gets its "command" executed. Attributes like v_foo would be just temporary variables used to make changing things easier and could be skipped in the interests of more concise entries. Somewhere, of course, you'd have a global object which defined attributes of its own for controlling the overall ordering of classes, e.g. "fs swap serial net cleanup quotas user", and so on. Browsers could inspect this object for hints on how and where to display the rest of the objects and also perhaps store their metadata here. Needless to say, I also see such a system _replacing_ the current one and available as an option, just as upgrading one's /etc mechanisms has essentially always been. I've seen 2.1 systems using their old /etc dirs after being upgraded to 3.0 no problems - as long as it's still self-consistent and nobody tried to upgrade just half of it or something, it works. That means that the purists can choose whichever suits them and I suppose that we could even make the choice an installation option. Unless you want to play some very clever and bizarre tricks with an "etcfs" using portals or some such, going for full backwards compatability is going to be nothing more than an impediment to doing this. It's technically possible, sure, but also annoying enough that it's more likely that you'd simply punt the project before making it do all the good things that a new startup configuration mechanism should do and be also fully backwards compatible with all the old files. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message