On Fri, 5 May 2000, Hubert Feyrer wrote:

# On Fri, 5 May 2000, Eduardo Horvath wrote:
# > I think a reasonable compromise is to have the rc.d scripts set variables
# > that can be overridden in rc.conf, and some utility to synchronize rc.conf
# > with the rc.d scripts when the system configuration is changed.
# 
# ... and init.d to switch on/off services, instead of service=YES/NO
# one-line config files.
# 
#  - Hubert

1.  init.d would be confusing to quite a few people, I think.

2.  The configuration you are proposing is IRIX.  I will state flat out that
    IRIX is brain-dead.  Most people coming to NetBSD from outside are going
    to be bewildered at these two points if they get implemented (please
    don't).

3.  The rc.d scripts shouldn't have the config information in them.
    "That's why we have rc.conf in the first place."

4.  It's been proposed not to have evaluations of variables for parameters.
    That would be breakage in the amd setup.  This is a relatively minor
    nit, but it needs to be addressed in a sane way.

5.  Maybe rc.subr's routine should check for the EXISTENCE of a variable
    instead of checking its value.  That would simplify things greatly,
    but it would require some adjustment on the parts of us SAs :-)

6.  If we have to do rc.conf.d, fine, but only fine if we can make the
    choice of which of rc.conf.d/* and rc.conf take precedence.  This can
    be done.  In fact, a missing rc.conf.d should not be an impediment
    to either daily operations OR an upgrade(!).

    Code in rc.subr and lines in rc.conf which state something to the effect:
    # Variable override preferences:
    #	file - use values /etc/rc.conf
    #	dir - use values from /etc/rc.conf.d
    conf_var_preference=file
    # Action to take on conflicting information on STARTUP only.  Shutdown
    # action is "warn"[%]
    #	fail - do not start the service in question
    #	warn - start the service in question
    #	abort - abort the startup immediately and drop back to single-user
    #		mode.

[%] could be silent considering you already saw the warnings on startup.


		And on to another controversial topic.

By the way, it's pretty evident to this wolf that runlevels are going to
enter the picture.

As a further aside, since I seem to have this knack of calling open() on
the value returned from an array of pointers to functions returning pointers
to arrays of cans of worms, I figure why not stir up the whole pot.  Let's
get all this BS out of the way.  I will also maintain that there are ways
to maintain warm fuzzies.  The question is, "will NetBSD be willing to make
the place comfortable?".  I'll share any warm fuzzies I can codger up.

...and I only have to say this on runlevels:

If I cannot configure what happens when I type 'boot -s', or if I am
confronted with

	ENTER RUN LEVEL [0-6Ss]:

when trying to leave single-user mode (i.e. it doesn't know how to configure
it), or if our run-levels are restricted to single-character idiocy, it's
broken.  I was going to say something about signal hackery, but our init
uses a smaller subset of that already, so I can't say ours is broken based
on that fact, but I would recommend that the signal hackery not be expanded
beyond its current scope -- use a socket/pipe to communicate one's intentions
with init.

A single-user shell is quite useful; I think the way that SysV handled it
("Filesystems damaged, entering single-user mode, type EOF to continue"
 followed by a shell on top of the startup process!) was badly broken.
We should continue our current practice that if single-user mode is desired/
needed, all startup in process should be aborted, and we should drop back
to a su shell as the only thing running.

Someone's gonna correct me and say "That's not what we have now".
That's okay.  I'm just saying that's the way it ought to work.

				--*greywolf;
--
BSD: Tap The Power.