From owner-freebsd-hackers Tue Apr 1 14:20:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06872 for hackers-outgoing; Tue, 1 Apr 1997 14:20:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA06841 for ; Tue, 1 Apr 1997 14:20:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA12164; Tue, 1 Apr 1997 15:02:55 -0700 From: Terry Lambert Message-Id: <199704012202.PAA12164@phaeton.artisoft.com> Subject: Re: Internal clock To: nate@mt.sri.com (Nate Williams) Date: Tue, 1 Apr 1997 15:02:55 -0700 (MST) Cc: proff@suburbia.net, nate@mt.sri.com, hackers@freebsd.org In-Reply-To: <199704012008.NAA05197@rocky.mt.sri.com> from "Nate Williams" at Apr 1, 97 01:08:42 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > That philosophy guarentees one to failure. The code doesn't have > > a chance of being supported till it gets exposure and people start > > relying on it. > > No, someone has to integrate it (hence support it). If, for example, the character device driver to system interface were relatively static (which it could be if it were well designed and thought out in the first place, instead of being incrementally revised every Tuesday), then a character device driver written to that interface would *never* "go stale". It would keep it's utility indefinitely (code can be crufty, yet maintain utility) because, even though it was outdated, it would continue to function as it was intended, without additional maintenance. Interface changes are the predominant cause of maintenance hassles. Arguably, the person changing the interface is responsible for doing the associated maintenance for all consumers of the interface. At least that's what I'm told every time I want ot make VFS changes: that everything that currently works has to keep working. I don't see any reason to not apply this standard uniformly... so even if the interfaces keep mutating instead of settling down (like they should, if they were NP complete and functionally abstracted), there is no good reason to not include code which is not expected to be maintained. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.