From owner-freebsd-hackers Mon Jun 29 16:31:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03299 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 16:31:03 -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 QAA03279 for ; Mon, 29 Jun 1998 16:30:53 -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 QAA05259; Mon, 29 Jun 1998 16:29:31 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Andrew Reilly cc: Terry Lambert , Mike Smith , njs3@doc.ic.ac.uk, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Mon, 29 Jun 1998 16:24:34 +1000." <19980629162434.A20703@reilly.home> Date: Mon, 29 Jun 1998 16:29:31 -0700 Message-ID: <5256.899162971@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sorry for leaping into this late, (and consequently getting the > wrong people on the To: line), but what's the "90's" way of handling > the genuinely script-like things in /etc? I can see how a unified > parameter/value store would be a great advance for most things, > but how do you do: > > /etc/ppp/ppp.linkup.foo, the script that is executed by the !bg > line at the bottom of your ppp.linkup file. > > /etc/{daily,weekly,monthly} In some cases, you probably do nothing more than treat ancillary scripts as one big property, e.g. bring up a text edit box and just let the user edit the script. That should be workable within the proposed framework since nothing "higher up" needs to know or care that /etc/ppp/ppp.linkup.foo is an indivisable property all on its own and you'd just export it as ``net.ppp.foo.linkup_script'' or some such. In others, especially things like /etc/daily or even the /etc/rc.conf and /etc/rc.network pair (where one file sets hints on behalf of another file, which then does various hidden and arcane actions based on their values), it all comes down to how much you want to advance the state of the art in exchange for leaving the previous paradigm (and all those who were used to it), behind. To clarify what I mean, let's take the following real-life example from rc.conf: linux_enable="YES" # Linux emulation loaded at startup (or NO). which also has the corresponding code in rc.i386: # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi It doesn't take you long to realize "hey, waitaminute, this is pretty crude - if I want to add another variable to this scheme, I've got to go to rc.conf and add it there, then add it to the man page for rc.conf, then go figure out which of the rc.foo scripts has the code which is associated with that action and add another clause to it." Contrast this with a slightly different model, where you have one variable called "linux" in your ``registery'' with the following properties: linux(enabled) = YES linux(doc) = { This variable controls whether linux emulation support will be automatically loaded at startup. You can also do it manually with the /usr/bin/linux command. } linux(exec-command) = "linux > /dev/null 2>&1" This is far more concise and is missing only the information which tells us when we want to execute the relevant system command (it could, after all, have ordering prerequisites like so many of the network startup foo), and for that one could simply add another properties like "exec-order" and "exec-group" which would enable the system to group actions together and set their overall execution order within that group. Anyway, assuming that you could ever get the /etc/rc* proponents to stop screaming about such a gross violation of POLA in FreeBSD's startup code, and you were willing to suffer through all the emotional war stories about how *%$#$@! difficult it is to find and debug abberant startup behavior on SVR4 boxes and this was just a step in that direction, people would probably ultimately praise such a scheme as being far more concise, easy to extend and better documented (assuming that you adhered to some decent conventions on doc properties). But you're also not going to catch ME trying to hold up that particular lightning rod. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message