Date: Fri, 30 Oct 1998 00:12:12 +0100 (CET) From: Andrzej Bialecki <abial@nask.pl> To: Terry Lambert <terry@whistle.com> Cc: Bryan Mann <bmann@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSF.4.02A.9810292344200.3317-100000@korin.warman.org.pl> In-Reply-To: <3638C745.39FD@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Oct 1998, Terry Lambert wrote:
> 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.
Hehe.. So, we think similar sometimes... :-) This idea also occured to me
when I started thinking about dependencies.
> I think the important point is hidden in my naming the subdir
> "smtp" instead of naming it "sendmail".
Yes, definitely. I don't care what is the name of such and such process,
as long as *someone* provides this particular service for me.
> 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.
Now, yet another idea occured to me: in fact, the initial startup could
just try to start some highest level function of the system, and this
function (since it has multiple dependencies) would try to satisfy its
needs by requesting an "INIT" action from all service providers it is
dependent upon.
This is a nice picture, indeed.. it also means that if for some reason
one of these providers stops working properly, the higher level function
requests from it a restart procedure, which it can pass to the next level
down, which it knows is not working properly, etc...
> 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*.
I'd call them "critical" and "non-critical" to distinguish between the
situation when subsystem is still able to function (though perhaps
impaired) and the situation when such lack of provider is so severe that
the service cannot possibly be performed.
> 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.
Hmmm... I don't think this resolves the issue of deadlocks - it just moves
it to more abstract level of services, instead of real objects/processes.
The real problem (i.e. mutual "critical" dependency, like
depends on
1<----------2<--------3
| /|\
+---------------------+
) still exists.
> 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
??? I can't parse it...
Andrzej Bialecki
-------------------- ++-------++ -------------------------------------
<abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see:
Research & Academic |+-------+| "Small & Embedded FreeBSD"
Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/
-------------------- ~-+==---+-+ -------------------------------------
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?Pine.BSF.4.02A.9810292344200.3317-100000>