Daniel C. Sobral writes:
> Mike Meyer wrote:
> The multiple levels are there to deal with changes in state. In BSD, for
> instance, we have single user/multi-user. A number of other variations
> can exist, both in heavy duty servers where you might want to bring
> certain services down for upgrade and then back up, and "desktop"
> machines, such as notebooks where you can be stand-alone, docked into
> different networks (eg. home/work).
I'm familiar with why mutliple levels exist. I've never run into a
system that had a real use for more than three run levels - powered
off, maintenance, and up - though I've not dealt with
notebooks. Needing to shut down some services in the up mode, or start
some in the maintenance mode, is why having "start" and "stop"
arguments to the scripts in rc.d is nice. If you find yourself needing
to change to the state on a fixed bag of servers regularly, that
feature on the scripts allows any admin worth hiring to write scripts
to go back and forth easier than they can configure the SysV run
levels. This doesn't work very well for the notebook example, though.
> Thing is, SysV does it in a very ugly way, and not flexible enough
The functionality SysV provides isn't nearly worth the
complexity. That was why I decided not to bother with it. Supporting
multiple run levels adds lots of complexity. Tools to change run
levels, hooks into init, etc.
Possibly a simpler system - "run states" - which aren't layered like
the SysV run levels would provide most of the functionality without
anywhere near the complexity. The state transitions are all from
single-user (where rc.shutdown takes you) to and from different up
states, using different pairs of directories to rc the system. In this
case, the K* and S* filenames make more sense, so there's only one
directory per state. This would handle the notebook, and anything that
required some set of services to be turned on from single-user mode
> and my favorite substitute proposal:
Having working code makes it a lot more attractive than any of the
others - or what we've discussed here. It's also a lot more complex
that what we've been discussing. If you're willing to work on getting
this integrated into the core, cool. If not - then I'd still like to
see something that is easier to configure and deals with
startup/shutdown issues better.
P.S. - anyone else remember rc.single? Anyone care?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message