Warner Losh <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]> Doug Barton writes:
> : > in fact, the require keyword isn't sufficient in it's own. there
> : > should be pre_require and post_require keywords since nfsd needs to
> : > start mountd before to start nfsd then rpc.statd and rpc.lockd have to
> : > be started after nfsd.
> :
> : Cyrille has already made two excellent points, gold stars for him. :)
>
> But Cyrille's point isn't very good. nfsd doesn't need rpc.statd to
> start. To get the "thing" known as "nfs server" you have to start
of course, this was just an example. this assertion could be true for
every service you want to stop/start automagically our manually.
consider a machine w/ nfs started manually. it's pretty cool to just
say /etc/rc.d/nfsd (or whatever is it's named) start whether or not
rpbbind is started and see rpcbind started and so on.
> things, but that's different than just nfsd. There's now *NEED* to do
> that. It is a kludge that breaks the symetry of the NetBSD system for
if there's no NEED to do that, there's almost no NEED to switch from
a monolitic rc framework to something else if the life is not easier.
> little gain other than being different. and that's a big lose.
>
> Also, the whole idea of adding "requires" and "provides" code is
> really bad. The whole reason that NetBSD has these listed as keywords
> in comments is so that you can grep them out without having to start 2
> sheels per shell script to find these things otu. They had an eary
this is implementation detail. ok, in this quick and dirty example, I
use $() (aka `) but it's easy to get rid of them. I'm also pretty sure
than forking a subshell has no more cost than forking rcorder. it one
word, this is a bad argument :)
> version of this that was so slow they shit canned that part of the it
> (or maybe it was just back of the envelope calcs that killed the idea
> before it was implemented). This means that we can make it work on
> the low end systems, and NetBSD's boot won't take forever on small
> systems.
>
> : First, there are some weaknesses in netbsd's
> : system that we don't want to replicate.
>
> Speficially, what are these?
at least, the inability to start a subsystem and it's dependencies.
> I'd be happy to spend up to 20 hours working on this project.
> However, I don't want to spend 20 hours sniping and carping about how
> bad NetBSD's system is before it even gets ported. I'd do the port,
I'm not waying NetBSD rc framework is bad, I'm just saying it is
incomplete. I'm almost sure NetBSD guys would be interrested by such
enhancement to their framework. as you know, every BSD systems are
getting the bast of other BSD systems :P
> to the point it is ready to import and provide diffs for people to
> try. But I don't want to get in the middle of a pissing match to
> tweak the thing to the point that we can't reimport later work by
> NetBSD or produces soemthing that Luke will hate.
Cyrille.
--
home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular
work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
