From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:22:00 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED39910656AA for ; Wed, 8 Sep 2010 14:22:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA84B8FC16 for ; Wed, 8 Sep 2010 14:22:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 597E246BC0; Wed, 8 Sep 2010 10:22:00 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E2F48A04F; Wed, 8 Sep 2010 10:21:59 -0400 (EDT) From: John Baldwin To: vadim_nuclight@mail.ru Date: Wed, 8 Sep 2010 10:21:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009081021.48077.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 08 Sep 2010 10:21:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:22:01 -0000 [ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: > Hi John Baldwin! > > On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': > > > On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: > >>> Because the original I4B code didn't > >>> work without the Giant lock, and because no one stepped forward to fix > >>> that, the code had to be removed. > >> > >> No. The code needn't removal, the stack should be modified to be fast without > >> I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness > >> is their problem, not of the Project. > > > No, that would require maintaining two network stacks, not just one. The > > shims to allow unlocked code to run were not trivial. The choices were this: > > > 1) Moving forward on work to allow the network stack to scale on SMP > > systems (e.g. modern x86 multi-core servers) and support higher rate > > protocols such as 10GB, 40GB, and 100GB. > > > 2) Stop all progress on making the network stack scale on SMP. > > > I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a > > modern, relevant system. > > If it is the only variants, then I'll agree (but only on this part). Are there > really no other variants? What do other OSes to which, as was said, we have to > compete? E.g. Linux? Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core problem. OS's that aren't working on this will soon be obsolete. Even modern embedded systems are multi-core (e.g. many MIPs chips now include multiple cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs SOCs). > > Also, despite your claims to the contrary, there _was_ adequate notice: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html > > This was also documented in the release notes for 7.0: > > http://www.freebsd.org/releases/7.0R/relnotes.html > > No, my claims were that there was no _adequate_ notice, and this links > acknowledge this. 7.0 Release notes state about broken ISDN as an already > happened fact, user can't do anything about it already. As I've shown in > message to vwe@, it wasn't in announce@ and even in stable@. Number of > users/subscribers of lists can be expressed as: > > # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD users > > While we can't do anything with those who not subscribed even to announce@ > (though should it be duplicated on www may be?), number of announce@ readers > is still MUCH more than that of current@, not even mention devel lists. We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. I do think stable@ is a good place to e-mail, and I did in fact mail my locking patches for the various NIC drivers to stable@. In some cases I did only find testers via stable@ and not via current@. I do think that the general rule is that stable@ should be on the list. It is true that that did not happen in this case (and probably should have), but it does happen in the typical case. I would chalk this up to a one-time slip-up, not a systemic problem. > > If you wish to help work on ISDN support, I suggest you offer to test hps@' > > ISDN stack. hps@ recently became a committer so I think there is a very good > > chance his code will be brought into the tree. > > We do have a policy for removing code in that it only gets removed if no one > > is able to maintain it and/or test patches for it. I locked several of the > > remaining NIC drivers during the push to remove Giant and a few of them were > > removed from the system because no one had the hardware around to test the > > patches to add locking (think of really old ISA NICs that only do 10Mbps). > > Big thanks for your work, but unfortunately, the problem itself is not ISDN or > network stack, it is deeper. It is the policy or may be style of thought, > discourse. Something like: > progress dictates we need fix/maintainership to feature X > & we have no resources to maintain feature X > -> we announce theis need, but only to _limited_ audience, not wide circles > -> nobody responds > -> the X code is removed > AND we think this logic chain is correct, thought we did not things this way > even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). -- John Baldwin