From owner-freebsd-hackers Tue Sep 26 23:48:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16054 for hackers-outgoing; Tue, 26 Sep 1995 23:48:01 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16049 for ; Tue, 26 Sep 1995 23:47:58 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id BAA07563; Wed, 27 Sep 1995 01:46:27 -0500 Message-Id: <199509270646.BAA07563@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Coranth Gryphon cc: hackers@freebsd.org Subject: Re: ports startup scripts In-reply-to: Your message of "Tue, 26 Sep 1995 03:33:42 EDT." <199509260733.DAA16047@healer.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 27 Sep 1995 01:46:27 -0500 From: Jon Loeliger Sender: owner-hackers@freebsd.org Precedence: bulk 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