Date: Tue, 25 Apr 2000 10:49:21 +0100 From: Paul Richards <paul@originative.co.uk> To: "Brandon D. Valentine" <bandix@looksharp.net> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, Alok Dhir <adhir@forumone.com>, 'Richard Wackerbarth' <rkw@dataplex.net>, 'Matthew Dillon' <dillon@apollo.backplane.com>, "'freebsd-current@FreeBSD.ORG'" <freebsd-current@FreeBSD.ORG> Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <39056A21.C58ED54A@originative.co.uk> References: <Pine.BSF.4.21.0004242247020.29270-100000@turtle.looksharp.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Brandon D. Valentine" wrote: > > On Tue, 25 Apr 2000, Daniel C. Sobral wrote: > > >Because if we do not provide a STABLE ABI, we WON'T get third-party > >(binary only) kernel modules. > > > >I'm very divided in this issue. 4.x has just started, and would be > >seriously impaired if no further improvements to it's SMP get in. On > >the other hand, if we can't garantee third party vendors a stable ABI, > >we won't get third party vendors. > > The number one excuse large third party server vendors use to justify > use of NT over Linux on their high end SMP systems is the poor > performance of Linux SMP. This is a tremendous opportunity for FreeBSD > to take market share. People are seeing the virtues of free, open > source operating systems in the server farm and providing top notch SMP > support in FreeBSD will help to see that we make further inroads that > the Linux guys do. If the BSDi code assists us in improving SMP > performance and if the corporate backing helps our PR image, then we > could be in for a fun ride. This is the time to start thinking in terms > of "What can we do better?" or we're going to lose the battle. Sure, > those changes could go into 5.x and be released when RELENG_5 is > branched a year from now. But in this business, a year is 6 months too > late. Think about that before you object to what appear to be vast > improvements in the performance of the RELENG_4 branch while it is just > getting off the ground. I totally disagree, my experience is that commercial users upgrade not more than once a year and they expect things to continue working on their chosen branch for that year and to continue to receive bug fix support on that branch (most places upgrade much less often than once a year). "a year is 6 months too late" is true for development branches but it is not the case for production code. Having a happy user base will mean that a FreeBSD 5 with improved SMP will be anticipated and widely adopted when it is released sometime next year (I'd hope). The more we piss off the production users with unnecessary incompatibilities in stable branches the more entrenched they become with their existing releases, regardless of the improvments in later versions, because they don't trust the project to have a professional release strategy. I've seen this happen already and early adopters of 4.0 are going to be really pissed off to find that there is an ABI change in a stable branch. Most commercial users are not developers, and have no interest in anything relating to development. Professional sysadmins are conservative creatures, they expect professional quality code to play by the rules of the industry and those rules are widely accepted as meaning that stable branches do no undergo ABI changes. Such changes are reserved for major upgrades because of the consequences and risks involved. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39056A21.C58ED54A>