I bit the bullet and installed /etc/rc.d (preserving VERY CAREFULLY my
old /etc/rc* setup).  The bullet has exploded, removing my front teeth
and my sinuses.  Thank goodness for small favours -- it's allergy
season here! :-)

Man, what the hell were you guys SMOKING when you implemented this?
And who's your dealer?  That stuff has to have been good and the way
life is going right now for me, I could use some.

Sarcastic?  Okay, okay, a bit overdone.  Sorry.

I will commend the concept.  It does let one go in and start/stop
on a very modular basis, which is cool.

Now, then.  Here are the problems I'm having:

1.  It's slower starting up, as in a power of two slower.

2.  It's slower shutting down, as in a power of three slower.

3.  /etc/rc.d/xdm assumes an installed base dir of /usr/X11R6 for the
	X stuff.  It also assumes that /usr/X11R6/lib/X11/xdm/xdm-conf
	is where the config file is installed.  Both of these
	should be configurable, somehow.

4.  The rc.subr seems to have a routine for checking out a process,
	yet if the pid lookup in /var/run/*.pid fails, the process
	is assumed not to be running.  Bad Move.

5.  sh xdm restart passes its args in as "run_rc_cmd xdm restart reload".
	This is a bad assumption.  Once you start it, why are you HUPing
	it?

6.  sh network stop does not take down the network interfaces.  This is
	especially bad for rc testing.  As I *always* do when I'm running
	something with which I'm not familiar, I test from single-user
	mode, and I run "sh /etc/rc".  I got to the "network start" part,
	and the ifconfig hung trying to configure an interface that was
	still up.  "sh network stop" did not take the interface down.
	"network" needs an "unconfig" or "down" arg.

7.  xdm (again) still manages to start before rc is done, thus
	causing getty to start AFTER the xconsole pops up.  Getty then
	thinks that /dev/console is in use and complains every 30 seconds
	about restarting too quickly.

8.  If it starts from /etc/rc, there should be a mechanism in place to
	preserve the original output style.  This is purely cosmetic,
	but I think it's much nicer to see:

Starting rpc daemons: portmap ypserv ypbind yppasswdd bootparamd.

	than to see:

Starting portmap.
Starting ypserv.
Starting ypbind.
Starting yppasswdd.
Starting bootparamd.

	Perhaps a check could be done to see if it's being run from
	the command line or from /etc/rc.

So there's definitely some tuning to be done here.

I have ideas regarding performance:

	From /etc/rc{,.shutdown,.local}, the files could be sourced
	instead of run.

	There could be a conditional check to determine whether or
	not rc.subr and rc.conf had been run already.

	>> we could built the 'test' command into sh <<

I can't help but think that this would improve the startup rate.

As far as what to do regarding the network script and the interfaces,
I don't have any ideas there, except that a "stop" would actually
down the interface(s)!  Either that, or the reason as to why ifconfig
hangs on an already enabled interface should be discovered and soundly
trounced.

				--*greywolf;
--
BSD: We Come In Peace.