Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)

[John Baldwin]

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.

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

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).
Even in that case, the code will always live on in the source code control
repository's history.  That means it can always be resurrected if someone shows
up who will maintain it and keep it up to date.

At this point I think this thread has reached the end of its usefulness.

-- 
John Baldwin