Subject: Re: take2...
To: None <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 12/02/1999 14:44:20
On Thu, 2 Dec 1999, Luke Mewburn wrote:
: Vendor scripts would have to be modified to have the appropriate
: PROVIDE/REQUIRE/BEFORE lines if you wanted them to start at a
: particular point. If not, they will be started sometime at the end,
: with all the other scripts that are at the `end of the chain' (this
: is part of rcorder(8), and that program could be tweaked to change
: this behaviour).
I'd expect scripts to need to be modified--even if only adding a
"wrapper"--if they needed _any_ special start order other than "run sometime
after the rest of the OS has started up". The 1.4 and earlier state of
affairs was no different.
: You'd have to give me a really good reason for arguing for the
: larger/messier version which doesn't use run_rc_command,
: especially since the run_rc_command version is easier to read/debug.
I don't really see what's stopping us from allowing a script to use
run_rc_command _or_ parse the arguments at the script author's choice.
On Thu, 2 Dec 1999, der Mouse wrote:
: > 5. The old /etc/rc style. Dispense with it. It's nothing but a
: > speed hack, really,
: Not at all. It's also an immense boon to humans that have to have
: anything to do with the boot process. I've used SysV-style split-apart
: boot scripts and I've used BSD-style monolithic boot scripts, and for
: human frobbing, the BSD style is far easier.
I used to be in the same opinion, but I've found that most human frobbing
involves reordering something or changing a hardcoded value (which should,
indeed, be made configurable). With the proper granularity[*] and a
repository, or at least a human-readable index of repositories, of config
info, the goal of not having to frob anything can be attained.
[*] This means VERY modular scripts. Typically, the speed lost by multiple
scripts can be regained by "source"'ing [". filename"] the scripts rather
than running them in subshells. With that done, the modules could be as
granular as things like "mount_nfs_disks" or even "mount_usr_local" (a
user-created script, from a template, or even an internally parsed action
What I don't remember seeing in many of the proposals is an easy way for a
user to add dependencies in cases where the scripts would otherwise be
executed in arbitrary order [without modifying a particular script]. I'd
venture a proposal to have such a configuration file, so that you could say:
mount_critical_fs: nfs_client mount_stand
and get your NFS partitions and /stand mounted before things that needed
...Or maybe I've just had too much caffeine today....
-- Todd Vierling (email@example.com)