Date: Fri, 18 Apr 1997 15:32:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, dennis@etinc.com, nate@mt.sri.com, freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) Message-ID: <199704182232.PAA03133@phaeton.artisoft.com> In-Reply-To: <199704182157.PAA24998@rocky.mt.sri.com> from "Nate Williams" at Apr 18, 97 03:57:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > If you're talking about something else, then you are running a slightly > > different definition of "smoothly" or "integrated"; there is no inherent > > reason FreeBSD has to have any code, whatsoever, in common from version > > to version, except to deal with legacy issues. Even then, common code > > isn't really required -- only common interface points that don't change. > > That's total BS, and you know it. Almost *always* fixing bugs requires > API/interface changes. That's the nature of the beast, and you know it > as well as anyone, only you're trying to stir the pot again. It's possible to engineer good interfaces, just like you engineer a light socket. How frequently does the form factor on a light socket change? But lightbulb designs change every day, as do lamp designs. But the socket design remains the same because it is an overall good design. The problem is that it requires a high degree of up front planning (so far, unacceptably so for any free software project that I am aware of, with the possible exception of IMAP4, but then that's the exception to prove the rule, and Mark Crispin's a code stud, anyway). If FreeBSD had an NT-like HAL, where the hardware services were less dependent on the nature of the hardware suppling the services (look at the console and pcaudio code for a counter-example), the internal interfaces would be subject less to the vagries of change. There are other areas besides a HAL which inter-kernel-component interfaces would do a lot to shut detractors like Dennis up, by giving them what they want without hog-tying yourself in the process. For an example closer to home, the SVR4 interfaces for the DDI/DKI are highly stable (even if their VFS bottom end and module interfaces are utter crap). In that one area of the kernel, they have been able to supply a relatively stable platform for third party developers to insulate them from major changes between OS revisions. Even in the case of interface changes, when they do occur, they can be done in an evolutionary way, without being sacrificing the ability to revolutionarily change the black boxes which export the interfaces (or the black boces from vendors like Dennis, which plug into them). Streams is another example, distasteful as it is, that one can accomodate vendors with a stable interface without sacraficing the ability to make relatively unfettered progress. A streams driver moving from SVR4.2 to SVR4.2 ES/MP (SMP) does not even need recompilation, though it will be locked against thread reeentrancy at the top and bootom end queue accesses. 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?199704182232.PAA03133>