Date: Tue, 1 Apr 1997 15:02:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: proff@suburbia.net, nate@mt.sri.com, hackers@freebsd.org Subject: Re: Internal clock Message-ID: <199704012202.PAA12164@phaeton.artisoft.com> In-Reply-To: <199704012008.NAA05197@rocky.mt.sri.com> from "Nate Williams" at Apr 1, 97 01:08:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704012202.PAA12164>