On Thu, 28 Dec 2000, Brian Chase wrote:

> 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'.
> >
	Agreed, but if it proves that it gains significantly on slower
	machines, it might be nice to have an rc.conf option to enable it.

> > Perhaps we want a third extension to correspond with .sh to do this trick?
>
	Could do, though it starts to get ugly.

> Can you explain what you mean by that in a little more detail?
>
	We have three types of file in rc.d
		should be in subshell
		should not be in subshell
		can be either in subshell or not.

	rc.d currently handles the first two types. The back I posted
	switches everything to the first type.

> 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.
>
	That would be ideal.

> 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.

	We need to confirm its the new shell invocations that are costing
	most of the time. Can someone test the rc.subr I posted earlier
	and confirm that? If it is, then an 'rc.d compiler' may be a good
	option for people, but I'm wary of making it the default.

		David/absolute		-- www.netbsd.org: No hype required --