Date: Wed, 11 Dec 2002 17:41:28 -0800 From: Tim Kientzle <kientzle@acm.org> To: current@FreeBSD.ORG Subject: Re: RC NG, ntp and routed Message-ID: <3DF7E948.9060508@acm.org> References: <bulk.90313.20021211100352@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The point of the barrier scripts is to provide
simple dependencies to other scripts. In particular,
NETWORKING should represent a fully-functional
network, including any routing or multicast routing that is
normally used on this network. It does not, in itself, depend
on any filesystems. (It runs no programs itself, so why would it?)
There are not going to be many scripts that require partial
network functionality; I see little advantage to defining new
barriers for a partially-working network.
Whether NETWORKING or FILESYSTEMS comes first is irrelevant,
since neither one requires the other. If a particular network
script requires a local filesystem, it should say so:
REQUIRE: filesystem_local
or, if you prefer,
REQUIRE: mountcritlocal
Likewise, a filesystem script that requires full
or partial networking should say so. Again, FILESYSTEMS
itself does not require any networking.
It would be nice if there were some way for the filesystem
mounting scripts to PROVIDE those filesystems that they actually mount.
Then other scripts could, for example, REQUIRE: /bin, /usr/local
to ensure that the tools they need are, in fact, present.
Unfortunately, I don't see any way to do this with the
current rcNG system.
There are a couple of approaches that might provide such
functionality, but all the ones that come to mind require
dumping rcorder and integrating order calculations into
rc.subr. (In particular, you can't always know
what features a script has provided until it has run
to completion.)
Gordon Tetlow asks:
> Does anyone have a problem with dyking out the NetBSD
> specific portions after 5.0?
I certainly don't. <grin>
Mike Makonnen suggested:
>>>... let's move the routing daemons from /usr/sbin to /sbin.
To which Gordon Tetlow responded:
>>Lest we forget, / is statically linked. that 42k binary
>> turns into a 450k binary in /sbin.
There's work in progress to convert / to dynamic linking.
_If_ that work is accepted by the group, then that would address
Gordon's concern. Of course, a dynamic / does not give carte
blanche to move the entire world into /sbin, either.
I also agree with the poster who pointed out that folks who
have a remote /usr and rely on dynamic routing can easily
work around this issue on a case-by-case basis. The whole point
of having fine-grained rc.d scripts is to simplify customizations.
Tim Kientzle
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DF7E948.9060508>