Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Jan 1999 23:37:10 -0800 (PST)
From:      Julian Elischer <julian@whistle.com>
To:        Wes Peters <wes@softweyr.com>
Cc:        Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, hackers@FreeBSD.ORG, Robert Withrow <witr@rwwa.com>
Subject:   Re: more modular rc/init/uninit system...
Message-ID:  <Pine.BSF.4.05.9901312332270.304-100000@s204m82.isp.whistle.com>
In-Reply-To: <36B5556B.1957A699@softweyr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
sounds like you arwe describing the process
that we use to control the interjet.

all system activities are assigned  dependencies, including such things as
"hostname was changed"  and similar events.
If you indicate such an event the dependency graph is traversed and all
services that have such a dependency are notified or restarted.

Of course it's very interjet specific.

so of course it IS doable..
but it requires a lot ofinfrastructure, and of course we are running a
very predictable environment
where we know all activities being run under freeBSD onth e Interjet, as
well as the hardware configuration. So our dependencies can be
hardcoded..

julian


On Mon, 1 Feb 1999, Wes Peters wrote:

> Peter Jeremy wrote:
> > 
> > Peter Wemm <peter@netplex.com.au> wrote:
> > [make vs tsort]
> > >The advantage of make is that you could do a 'make -j12 boot' style thing
> > 
> > There's no reason why you can't automatically build a makefile from
> > a list of dependencies embedded in the scripts.  The script to do this
> > would be very similar to the script used to generate the input to tsort.
> > 
> > I think the concept of allowing arbitrary `run level' names with
> > arbitrary dependencies is more important than whether it is implemented
> > using tsort(1) or make(1) to resolve the dependencies.
> 
> Agreed.  What external programs are called in the process is immaterial;
> as usual in the UNIX world we have an embarrassment of riches.  ;^)
> 
> So, let's define some baseline wishes here, then discuss how one might
> go about implementing them.  I'll try to list what I've seen here so
> far.
> 
> o The ability to start and stop individual subsystems, and start/stop
>   all dependent subsystems.
> 
> o The ability to specify some sort of alternate configuration name on
>   system startup, for instance to move between an ethernet and PPP
>   configuration.
> 
> o The ability to add a package into the system configuration without
>   editing existing scripts; each package configuration file should be
>   standalone and self-contained.
> 
> Did I hit the high points?
> 
> I really think this is doable, if we can figure out what it is that
> we're trying to do.  So far, Robert Withrow's proposal with each
> script providing a standard set of shell functions is looking pretty
> promising.
> 
> -- 
>        "Where am I, and what am I doing in this handbasket?"
> 
> Wes Peters                                                 Softweyr LLC
> http://www.softweyr.com/~softweyr                      wes@softweyr.com
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901312332270.304-100000>