Date: Wed, 8 Sep 2010 10:21:47 -0400 From: John Baldwin <jhb@freebsd.org> To: vadim_nuclight@mail.ru Cc: stable@freebsd.org Subject: Re: Policy for removing working code Message-ID: <201009081021.48077.jhb@freebsd.org> In-Reply-To: <slrni8f5pi.2k1s.vadim_nuclight@kernblitz.nuclight.avtf.net> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <slrni8f5pi.2k1s.vadim_nuclight@kernblitz.nuclight.avtf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009081021.48077.jhb>