Policy for removing working code

[John Baldwin]

[ 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 at . 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 at .  In some cases I did only find testers via stable@ and
not via current at .  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