Date: Thu, 29 Oct 1998 11:51:33 -0800 From: Terry Lambert <terry@whistle.com> To: "Andrzej Bialecki terry@whistle.com" <abial@nask.pl> Cc: Bryan Mann <bmann@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <3638C745.39FD@whistle.com> References: <Pine.BSF.4.02A.9810291134310.20293-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrzej Bialecki wrote: [ ... dependency ordering enforcement ... ] ] Perhaps Terry can look at it from theoretical point of view ] (I've heard him once discussing graph theories and the likes ] :-) - but common sense tells me that when you have several ] objects with mutual dependencies, there is good chance that ] they will create loops (resulting in deadlocks). ] ] So, I think we need to address this issue from start, so that ] later, when we start implementing it, we know how to avoid ] them and how to unwind such loops when we create them by some ] configuration action. Deadlock detector is a good thing, but ] deadlock avoider is still better... :-) I think the missing piece here is that the dependency relationship enforcement implies a "natural order" in which things are to occur. I don't think this is more complicated than dealing with "make depend" and/or "make -j8". You *could* replace the entire rc file system with /etc/startup/Makefile, and everything you install that need startup gets a subdir, as in somthing like /etc/startup/smtp/Makefile, and there is an implied recursive descent into subdirectories. This is way overkill, of course; if you had flat files, you could do the same thing with scripting using tsort. 8-). I think the important point is hidden in my naming the subdir "smtp" instead of naming it "sendmail". The roundevous point has got to be the definition of what is exported by a server, and what is imported, not the server name, and not the definition. For example, sendmail exports "smtp", and it imports "dns"... so you don't want to start sendmail until its imports are satisfied. We could also see a sendmail-with-ldap-patches-applied (since such patches are currently publically available), which would mean that, in addition to "dns", it required "ldap". It's rather irrelevent that the service "dns" is exported by bind, or that the service "ldap" is exported by slapd (or that we may be importing the service "ldap" over the network from another host because we don't have a disk to store user data other than hard-coded bootstrap information). The point is that each server has a list of dependencies. Now consider a server that exports "dns", and wants to send out usage reports via "smtp". There is a dependency of this server on "smtp", and there is a dependency of the server that supplies "smtp" on "dns". But there is a distinction: the dependency to send reports is *soft*, while the dependence of the "smtp" exporting server is *hard*. We can think of the "dns" exporting server as actually being in the business of prividing *two* services: the hard service "dns", and the abstract service "dns usage reports". These are seperate, and the "dns" service can be brought up before the "dns usage reports" service. We can also see that both these servers will probably have other dependencies, like "syslog", a service that needs to be defined as existing defacto, if it is on another server (we can say the same thing of "smtp" and "dns"; nothing states that these services must all reside on the same host). So I think the problem is resolvable; it's just an issue of establishing that you're really dependent on services, not daemons, and then using a sufficient granularity for your definition of services to avoid starvation deadlocks. Of course, we are ignoring the real issue here, which is that most services only exist in the first place because we insist on having a procedurally abstracted configuration space. Why do you need to restart a daemon that needs the host name; why doesn't it call gethostname(3) each time, or why doesn't the hostname live in a read-only mmap'ed configuration space, so that the cached copy is the real copy, and is always up to date? But that's a different discussion... 8-). -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3638C745.39FD>