HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

[Robert Watson]

On Wed, 8 Sep 2010, Vadim Goncharov wrote:

>> Which part of "support for the Giant lock *over the network stack* was 
>> removed" [emphasis mine] do you not understand?
>
> No, component removed was (1), I've underlined.
>
>> The reason is performance for overall network stack, not ideology.
>
> For a practical reasons, "it works but slow" is better than "doesn't work at 
> all (due to absence of code in the src tree)".
>
> "Make it work. Make it right. Make it fast. In that order", know this? 
> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is 
> it?..

Doug has already clarified, but just to follow up with some detail:

Moving to a parallel network stack required that all portions of the stack 
code be updated to operate without the Giant lock present -- the Giant lock 
was a fundamental assumption in all kernel code in FreeBSD 4.x and earlier. 
This decade-long project was highly successful, and relied on members of the 
community stepping forward to adapt a very large code base by adding 
fine-grained locking to each component.  The results have been extremely 
impressive, allowing our network stack to scale to 8+ CPUs (I'm actually 
testing with 32-thread systems as part of some network stack work I'm doing 
right now).

Towards the end of the project, it was clear that a few components in the 
stack had attracted no interest from the community, and as such, were not 
going to get updated.  As such, we went through a public deprecation and 
removal process, in which we appealed repeatedly for community members to 
update the code.  This included i4b, one of our three ATM implementations, and 
one of our two IPSEC implementations.  I've attached the i4b schedule below (a 
three-year process), but you can find information on the full process here:

   http://wiki.freebsd.org/NONMPSAFE_DEORBIT

This was not an issue of i4b operating more slowly than the rest of the stack: 
it was that the code required fundamental architectural changes without which 
it couldn't compile, let alone run.  We're all happy to have ISDN support come 
back in the tree if there's an owner for doing it!

In the end, any significant code base in the kernel requires ownership -- it 
can continue through many minor changes without an owner, but major retrofits, 
such as moving to fine-grained locking, need the attention of someone who 
understands the code, is able to test the code, and has the time to invest in 
the code.  We do a pretty good job at arranging this with a multi-million line 
code base, all told.

Robert

Date		Done	Event
18 July 2005	yes	Post MPSAFE network stack plan to arch at .
04 July 2007	yes	Disconnect parts of I4B from the build. HEADS-UP to isdn at .
17 July 2007	yes	Post NET_NEEDS_GIANT() reminder to arch at .
27 July 2007	yes	Remove NET_NEEDS_GIANT().
22 March 2008	yes	Last call to seek for help rewriting I4B to keep it alive.
15 May 2008	yes	Final announcement on isdn@ that I4B will be removed from 8/7.
26 May 2008	yes	Remove i4b from HEAD.