On Tue, Apr 25, 2000 at 01:29:41PM -0700, Greywolf wrote:
> 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.
	yep.  This has been discussed to some extent already.
> 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.
  Sure, this could help some.  Although if you've got individual
config files in /etc/config you're going to have to load all of
these before any individual scripts instead of having each one
know which one to load.  A little bit difficult when a rc.d script
uses a differently named config file.  (i.e. /etc/config/nfs used
by rc.d/{nfsd,nfslocking,mountd})  It also destroys the possibility
of limiting problems in one config file to the particular script
that needs it.
(no, the split config isn't done yet)

> 	>> we could built the 'test' command into sh <<
  Wasn't someone doing this already?

> 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?
   That was looking a bit funny to me too.  Anyone know what's with 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.
  This was discussed before.  The problem with having it ifconfig down
the interfaces is that you can cause the shutdown sequence to hang.
For instance, if you're shutting down to single user and you're NFS
mounting everything.  ifconfig definitely shouldn't hang if the interface
is already configured.  It doesn't for me.  How exactly is it trying to
configure?

> 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.
  This would require some changes to init to start some stuff before
gettys run and some stuff after.  This shouldn't be too hard, just need
to define something.  How about init runs /etc/rc again but gives it an
"aftergetty" argument?

> 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:
  eh, whatever.  go for it.

> 	Perhaps a check could be done to see if it's being run from
> 	the command line or from /etc/rc.
  or a variable set (like _rc_fast_run).  "_rc_singleline_output"?

> 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.
   so add more options.  How about setting a default X11BASE and having
rc.d/xdm use it?
	As for the config file, how about xdm_config="..." to set
the required_files variable.  And to tell xdm where to find the config
set the xdm_flags variable.

eric