[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rc

# On Mon, Aug 07, 2000 at 09:05:03PM +0200, Juli-Manel Merino Vidal wrote:
# > On Mon, Aug 07, 2000 at 02:51:54PM +0200, Marcus Brinkmann wrote:
# > > System V init has some deliberate limits (for example a fixed number of
# > > run-levels). For the hurd we want something better.
# > 
# > So, what will the hurd implement ?
# So makefile-ish init.
# I'm sure I found such thing for Linux somewhere in the web,
# but can't do it again :-(.

I had an idea about developing this for Linux (I wasn't aware some such
thing existed) - actually inspired by WinNT's "service" handling. The way
it worked was (briefly):

- Every service had several states:
    * Stopped
    * Starting
    * Started
    * Paused
    * Stopping
- Every service could be controlled by a pretty standard command (I used
the name 'svc' for my test program), which took the syntax:


Without the OPERATION, it displayed the current state of the service,
otherwise, OPERATION must be one of:
     * Start
     * Stop
     * Pause
     * Restart

And the configuration was managed by makefile-style files so that services
could depend on one another - the 'starting' and 'stopping states were
used primarily when starting/stopping dependencies, in order to prevent
startup/shutdown loops.

'Runlevels', as they exist now, were effectively pseudo-services, with
every service that ran in them being dependencies (I didn't quite get as
far as doing this bit, so things are still a bit hazy). I decided on named
runlevels, though, which was a) less confusing for the user b) allowed
more flexibility (init graphical, init multiuser, etc), and thinking about
it, c) is more fitting with how HURD goes (imho).
# > When ?
# Only good god knows.

If there's interest, I could start hacking something together - or at
least, getting a concrete design together?


Mo McKinlay             Chief Software Architect          inter/open Labs
GnuPG Key: pub  1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>

Reply to: