On Wed, 27 Dec 2000, Chuck McManis wrote:

> I haven't used it enough to decide if it succeeds where the others fail.
> However, the entire "rc.d" concept is based on the flawed (IMHO of course)
> assumption that a file system based database is ever adequate. Now the RC
> system "expressed" as a file system and based on a database? That might
> have some possibilities. But the problem that one is trying to solve is the
> one alluded to earlier:
>
>          "How can I customize the initialization and shutdown phases
>           of system operation in such a way that all dependencies
>           are accounted for and attempts to violate assertions of the
>           modules are disallowed?"
>
> And to solve this problem you need a vocabulary that can express
> interdependencies, transient relationships, and rules of invariance. The
> file system with its hierarchical names and symbolic links is not
> expressive enough to capture these attributes and hence applications to
> manipulate the same are overly complex and prone to failure.
>
	The above sounds very much like you have not even looked at the
	NetBSD rc.d system. There are no symbolic links, and dependencies
	are expressed in the form of 'a PROVIDES x' and 'b REQUIRES x'.

	Its not perfect, but arguably its biggest flaw in this context was
	picking the name 'rc.d' which causes people to classify it as
	'just another broken SysV/linux init.d linkfarm'. If you have a
	little time, please read the 'rcorder(8)' manpage and comment
	again.

> That said, I don't like or dislike the current rc.d/ system, I only share
> my observations with others that it places an excessive burden on less
> powerful compute platforms. Is that burden to much? Certainly that is a
> subjective question which can only be answered subjectively. Is that burden
> sufficient to prevent adoption of 1.5 on some platforms, the answer is
> clearly yes to that question.

	I believe the mips ports have made some improvements to the
	fork/exec code specifically to make rc.d workable. This has had
	obvious benefit to mips users when the system is running :)

	I agree rc.d does place a greater overhead on the system, and
	ways to reduce that would be very much welcomed.

	It would be interesting to see how a version of rc.d which
	always included the subscripts in the current shell would work.

	As another benchmark point - has anyone run any disk tests with
	NetBSD 1.5 with softdep enabled, vs disabled and earlier versions?
	Particularly on slower disks I'd expect the result to be a
	pleasant surprise...

		David/absolute		-- www.netbsd.org: No hype required --