From owner-freebsd-stable Mon Apr 24 10: 8: 4 2000 Delivered-To: freebsd-stable@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id 970A637B5F1; Mon, 24 Apr 2000 10:07:58 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA27091; Mon, 24 Apr 2000 10:07:36 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <39047F57.61D37EC4@gorean.org> Date: Mon, 24 Apr 2000 10:07:35 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "Jordan K. Hubbard" , "Rodney W. Grimes" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <10872.956523122@zippy.cdrom.com> <200004240617.XAA66270@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > So you guys (core) choose -- do you want 4.x to reap the benefits of > further SMP development or not? If you choose no, beware that without > this base cleanup there is *NO* chance whatsoever of any further SMP > work being MFC'd to 4.x. None. Zilch. It will have diverged too > much. I think that we can find a middle ground on this issue. Jordan made an excellent point in that this ".0" release has had more early adopters than any previous first release on a new branch. Therefore we want to take extra care to maintain the "-stable" perception of the 4.0-Stable branch. At the same time, Matt is correct in saying that the base of the SMP improvements needs to go into 4.0 now. The PR ramifications alone would be disastrous if the only place the SMP improvements were available was 5.0-Current. That would simply reinforce the perception that FreeBSD is nothing more than a toy for the developers. On the third hand (so to speak) is the fact that we really would like to be able to present a stable external interface to encourage third party developers to develop to the 4.x branch. So, my suggested compromise is this. Do the MFC now, with the caveat that this will be the only external interface change in 4.x-Stable. Architect out whatever changes have to happen, and make sure that the best guess as to what the interface should be gets committed, then stick to it, no matter how painful it is. It's still early enough to get away with this, but we can only "sell it" once, so let's get it right this time. I've got a fleet of SMP boxes at work, and given the coming instability of -Current I'd really like to stick with 4.0-Stable if I can, and in fact I've already made plans that relied on the work Matt's already done being MFC'ed as previously announced. I could probably justify the development time to track -Current if the performance gains were large enough, and in fact I'll probably put a machine or two on it to try and make a contribution to testing, etc. But speaking as a sysadmin the advantages of being able to rely on well tested changes that get MFC'ed on a regular basis for the majority of my machines would be a huge win. Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message