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-questions" 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>