Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Jul 1998 02:04:16 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jmb@FreeBSD.ORG (Jonathan M. Bresler)
Cc:        tlambert@primenet.com, joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   Re: FreeBSD equiv. of /proc/loadavg
Message-ID:  <199807030204.TAA17845@usr04.primenet.com>
In-Reply-To: <199807030027.RAA05728@hub.freebsd.org> from "Jonathan M. Bresler" at Jul 2, 98 05:27:17 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > What's NIH?
> > 
> > We can't tell you; the use of the term was Not Invented Here, and
> > thus, like SysV rc.d, we fear and mistrust it...  8-).
> 
> 	Oh Terry!  i dont like rc.d because i am left which
> 	"which of these scripts in which directory did what!"
> 	why?  grr....

You're not supposed to ask that question, because your package
management system takes care of that for you, and standard system
services are installed as packages, and the installation handles
the dependency enforcement for you.

In other words, it's a data-drop for post-validated dependent data,
not a respository for structural information used in validation.


> 	with our current strcuture, we have some separation without
> 	reaching the level of cookiness that sunos 5.5.1 provides:
> 	70 shell scripts scattered across 5 directories.

These are run levels, as opposed to run states.  Run states are
better, because I can define an infinite number of them, and I can
name them instead of numbering them (which I have to do in run
levels because of the sequencing requirements they imply).


I'd suggest that you don't have a way of dealing with:

1)	remove the "sendmail" module, which exports the "SMTP" service

2)	install the "qmail" module, which exports the "SMTP" service

3)	the "bind" module exports the "DNS" service

4)	the "qmail" module depends on the "DNS" service, so the
	"bind" module must be started before the "qmail" module.

due to the fact that the dependency relationships are coded in the
scripts, and not in the data that the startup process acts upon.

The installation needs to support the concept of "hard" and "soft"
service dependencies, and of "service export" and "service import",
of potentially multiple services, totally apart from the concept
of "this is what it takes to start a particular module".

The point of a script in an rc.d directory is "this is what it takes
to start a particular module".

Looking at it from the perspective of encoding the ordering and the
dependencies in the script names (as Solaris does) or in a shell
script (as FreeBSD does) is totally counterintuitive.

The concepts of "rc directories" and "this ``rc.statename'' means
this collection of services" are totally orthogonal to the idea
the "odd numbering of script names" in Solaris.


Just because Solaris supports only "hard" dependencies, and just
because it overlaods the file name instead of using a seperate
ordering hierarchy doesn't mean that a correct implemetnation
would have to do the same thing.


The only missing "baggage" is defining the rc.# "run level" service
clusters, and third party dependencies on having "at least the services
in the ``rc.3 cluster''" for the third party software to successfully
run.

Installation of third party software expecting the Solaris "rc.d"
mechanism would have to evaluate the service cluster(s) that the
third party software required by virtue of the rc.# files it tried
to install, and thereby determine whethr or not it should try to
start the third party software in the face of the ``statename''
cluster the user is running at the time.

That way, you get IBCS2/Solaris ABI compatability (the rc.d is part
of the ABI for server software).


Just because only *some* of the SysV rc.d ideas are good, doesn't
mean we have to make a choice between taking all of them, or taking
none of them.  Turning ranges into black and white choices is an
Aristotilian mean, and it's simply a bad way of thinking for any
true engineer worth his or her salt.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?199807030204.TAA17845>