> 	1. Using `shutdown' instead of `stop' as the argument to
> 	2. Adding the ability to specify a user to run as, a nice
> 	   level to run at,  etc. (xref PR 9954)
> The first two are about to be committed, barring serious objections.
> The rest probably need some more discussion.
	no problem with those.

> 3. Reworking the configuration mechanism (replacing rc.conf)

> 	If a tool is provided (e.g, virc(8)) which presents
>	/etc/rc.conf.d/* as a single editor buffer, which then
>	rewrites /etc/rc.conf.d [...]
    Which I believe exists in some form already.  See
http://gdev.net/~vpp/virc.tar.gz, written by Scott Bamford.
(I haven't tried this)

> 	From an implementation point of view, another rc.subr function
> 	- load_rc_conf() - would be used to load this config file.
   yes.

> 	Others have suggested very configurable configuration
> 	mechanisms [excuse the wording ;], but I feel that such
> 	proposals would result in making a system that was *too*
> 	configurable and harder for us (as a project) to support
    I was one of the people that suggested this.  After thinking
a bit on the impact this would have on the speed of the rc.d scripts
I agree with Luke here.  However, in an effort to keep some backwards
compatibility with a single rc.conf I think that the load_rc_conf()
function should unconditionally load rc.conf before the individual
config files.

I ran some speed tests on the different variations.  This is on
an AMD K6-233:
(and a comparison between old and new /bin/sh just for fun)

Ways to read config files:
				   New sh	    Old sh
				Time(s)	Index	Time	Index
1)	Individual files only:	0.11	1.0	0.81	1.0
2)	With full rc.conf	0.80	7.3	2.50	3.1
3)	Empty rc.conf		0.14	1.3	0.91	1.1
4)	With test for rc.conf	0.19	1.7	1.50	1.9

The script I used looped over 200 config files created from
the /etc/rc.d files.  All tests read these files in.  Test
#2 also did a ". /etc/rc.conf".  Test #3 instead read in an empty
file.  Test #4 tested for the existance of the empty file
before reading it in.  (slightly faster if it didn't exist)

The actual difference with the new /bin/sh (Test #1 vs #4) is
only .08 seconds.  Even on a machine that is 100 times slower than
mine this is only 8 seconds slower.  Since it helps everyone who
hasn't yet moved their config over to the split config scheme (==everyone)
I think this is an acceptable slowdown.
	Also, how about having /etc/rc check for /etc/rc.conf
and spitting out a message if it exists, saying that it is deprecated
and will go away in the next release?

> 	users. Having rc.d configuration information potentially
> 	coming from three sources (the rc.d/foo script, rc.conf or
> 	rc.conf.d/foo), with different variations on which source
> 	takes priority, sets off `difficult to support' alarm bells.
    Yes.  But, it would be nice if there was a specified default for
configuration information.  This isn't exactly configuration info but
a way to be able to reliably see what a particular rc.d script does
by default.  (which would generally be "nothing", i.e. off)  This would
also mean that you could have much cleaner configuration info that
only specified how a particular machine differed from the default.
The obvious place for this would be in the rc.d scripts, before
load_rc_conf() reads in any configuration.

eric