Date: Wed, 8 Sep 2010 14:01:22 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-stable@freebsd.org Cc: freebsd-security@freebsd.org Subject: Re: Policy for removing working code Message-ID: <slrni8f5pi.2k1s.vadim_nuclight@kernblitz.nuclight.avtf.net> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8704E3.5000408@FreeBSD.org> <slrni8ep2a.2h26.vadim_nuclight@kernblitz.nuclight.avtf.net> <201009080842.28495.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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. > 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. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrni8f5pi.2k1s.vadim_nuclight>