Date: Wed, 27 Sep 1995 01:46:27 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: Coranth Gryphon <gryphon@healer.com> Cc: hackers@freebsd.org Subject: Re: ports startup scripts Message-ID: <199509270646.BAA07563@chrome.jdl.com> In-Reply-To: Your message of "Tue, 26 Sep 1995 03:33:42 EDT." <199509260733.DAA16047@healer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, Coranth Gryphon scribbled:
> > There are issues here still, like, how do you state dependencies against
> > things that have yet to be invented? I think that's why fictitious or
> > virtual nodes may be needed in the graph too. They can essentially
> > arbitrarily represent the "levels" or "states" in the graph where
> > certain properties are available ("NFS", "LAN", "WAN", "Single User").
>
> Solves the dependencies problems if a specification can be coded.
Oh, it can be encoded, I'd bet...
> > Tip-toeing back out of the warzone,
>
> Nope, get back in here :-) This sounds like a really good idea.
Rats. OK, I'm back... Thanks. Do you think it is worth pursuing?
> So, how would you go about implementing such a dependency graph?
Well, the obvious one was to use ``make'':
Satoshi Asami was inspired to write:
> And the Unix way of handling dependency graphs are...yes, "make"!
> Can it get any simpler than an /etc/rc.d/Makefile?!? :)
This implementation can be done in several variants of which the
most promising is likely a set of "include"s. This, if nothing else,
would provide a "rapid prototyping" approach that might validate or
invalidate the whole approach.
Naturally, though, I bet this eventually isn't the right approach. Gut
feel says it doesn't handle all the needed cases quite right and will
eventually collapse under its own weight.
Perhaps a better approach might be to specify a general graph language
(nodes and arcs) and have a "scheduler" utility that constructed the
equivalent /etc/rc* files at key times. Initially at system install
based on normal /etc/rc behaviour, then at each pkg_add, etc.
I think the problem would be the "glue" between the parts. All of the
"state" information hanging in otherwise global variables in the /etc/rc*
files, interrupt and error handling, etc.
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509270646.BAA07563>