Luke Mewburn <lukem@goanna.cs.rmit.edu.au> writes:
> this is a tricky issue. for the `autogeneration' to work the script
> has to support argument `dumpstart' and `dumpstop', which output
> a series of commands which do what `start' and `stop' do
> (respectively).

This is losing.

There are lots of programs which already ship with scripts to properly
start and stop their daemons.  The one which pops into minde
immediately is ndc, though there are plenty of others out there for
third-party software.

Further, sysadmins everywhere have created many scripts to start local
daemons over the years.

Basically, what a scheme like this -- which requires additional
script commands -- does is either:

* force these scripts to be specially hacked for NetBSD (to add those
special commands), or

* force people to reimplement them with the happy shell-command
meta-language which seems to have been implemented.

From the point of view of maintainability, compatiblity with existing
systems (i.e. what people know about and understand), and getting
third party vendors to produce startup scripts which are useful with
NetBSD, I think this is less than optimal.

(we're still waiting on the description of how third-party scripts get
integrated into your world, unless i'm mistaken.)


In my perfect world, each there'd be a nice template init.d script
which showed the basic skeleton of what to implement (i.e. the
standard targets), then each individual init.d script would implement
those bits, plus whatever else you wanted to.  And, for instance, you
could just think of ndc or other similar scripts as things to symlink
into the init.d directory.  This is nice: every script shows you the
right thing to do, you don't need to read a twisty little maze of
shell functions to do it, and you've got literally dozens of good
examples of what to do.

The right way to create an /etc/rc isn't to magically put together all
of the commands from these files, it's to generate a list of commands
like:

	set -e
	/etc/init.d/foo start
	/etc/init.d/bar start
	/etc/init.d/baz start

In fact, i'd go so far as to say that a hard-coded /etc/rc should be
for die-hards only, and that the default would be something that
figured out what to run and ran it dynamically.



A couple of other points:

* i'm generally in favor of something like this... but I think this
method includes _way_ too much magic.

* part of the business of being OS developers is that we figure out
the right technical solution for the customers' needs is.  It's not at
all obvious to me that there's a real need to support all of the
features you have here.  (for instance: while static startup
configuration is nice, being able to generate the perfect /etc/rc from
that static startup configuration seems ... over the top.)

* it's not obvious to me how you can support fine grained ordering
_except_ by resorting to sysv S* and K* numbering.  how would you do
that useing the requires/provides features?  what happens to things
which generally depend on one set of features, e.g. networking being
up, but nothing else?  (i.e. how are they ordered, w.r.t other
things that also require just networking, and those which require
networking and more, but for which there are no actual dependencies.)
The nice thing about the sysv S* and K* numbering is that it's all
very explicit what's going on and when...


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.