On Thu, 28 Dec 2000, Todd Vierling wrote:
> On Thu, 28 Dec 2000, David Brownlee wrote:

> : 	"Its funny you should mention that..."
> :
> : 	I've just been playing with rc.subr (sample attached), and on
> : 	my 1.5 sparc box (no vaxen at work :/), the time taken to process
> : 	rc.d dropped from 41 to 35 seconds.
>
> The diff is running in the same shell, but part of the reason for the
> subshells is to allow the system to try to keep booting even if one service
> fails or one script has a shell bombo.  Additionally, third party scripts
> may do an `exit'.
>
> Perhaps we want a third extension to correspond with .sh to do this trick?

Can you explain what you mean by that in a little more detail?

I kind of would prefer it if there were some way to provide all the
functionality of rc.d at startup without involving so many processes, all
while maintaining a single implementation.

Still, if that's I'm fine with the idea of being able to generate a
monolithic startup script from the rc.d information, and use that for
slower systems.  Of course you'd still have to deal with stripping out or
otherwise avoiding gotchas like "exit" commands.  Maybe that's just a
matter of defining how rc.d scripts are to be written and weeding out
offenders after the fact?  It's not ideal, but I don't see it as being
horrible.

I think it'd even be pretty easy to have that monolithic script
automatically generated prior to the rc startup if any of the individual
rc.d scripts have been modified, added, or removed.

I do like the features provided by NetBSD's rc.d and I think they're more
useful than harmful.  I also think we're all smart enough to come up with
something that's a little more efficient on the slower systems and that
doesn't compromise the benefits of the new rc.d scheme.

-brian.
--- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----