Date: Mon, 29 Jun 1998 16:29:31 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Andrew Reilly <andrew@reilly.home> Cc: Terry Lambert <tlambert@primenet.com>, Mike Smith <mike@smith.net.au>, 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 Message-ID: <5256.899162971@time.cdrom.com> In-Reply-To: Your message of "Mon, 29 Jun 1998 16:24:34 %2B1000." <19980629162434.A20703@reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5256.899162971>