MFC of socket/protocol reference improvements

[gnn at freebsd.org]

At Fri, 16 Jun 2006 20:34:49 +0100 (BST),
rwatson wrote:
> I'm also interested in a line, but what I'm trying to determine is
> where the line falls: if we have a line around the set of "supported
> KPIs", a line we've never really drawn very well in the past, is the
> protosw KPI on one side of the line, or the other?  The status quot
> is that the line is fuzzy: in the past, we've changed related KPIs
> with some frequency, although I wouldn't call it wild abandon.  We
> can't say that no interface in the kernel is ever allowed to change,
> or what you'd get is a release rather than a branch, with almost no
> movement at all in the kernel.  Instead, we have to pick certain
> interfaces we choose to keep more static in order to support third
> party developers where it makes the most sense.
> 
> In the past, this has almost always meant device driver vendors,
> although file systems and netgraph modules have generally been
> treated fairly well.  It's made sense for two reasons: first, that
> it's actually possible and desirable to maintain the staticness of
> the KPIs, in part because we have large numbers of our own internal
> consumers and changing them all is apain, and in part because third
> parties actually have existed who ship products against them (such
> as video drivers, ethernet drivers, etc).  But what about protosw?
> Do these apply?
> 
> There are strong technical motivations to not support the protosw
> interface as a static KPI: this will allow us to continue to mature
> our network SMP implementation, close races, and add new features,
> such as SCTP (which relies on expanding the protosw KPI, which will
> break the ABI, FYI).  The question is whether there are strong
> technical or organizational motivations *not* to break it, such as
> an awareness that this is a KPI that third party developers actually
> ever program to and expect to remain static.

My thoughts on these changes are that, unlike device drivers, there
aren't hundreds of protocols that would be effected by a change in the
protosw.  Certainly there are more than existed in the past, but it is
very likely less than 10.  I think we need to also consider the fact
that these changes, which a lot of us are using/testing in HEAD, do
improve the performance and stability of the protocol used most often
in FreeBSD, that is TCP.  I think that for those two reasons we should
do this but ONLY at the end of the current release cycle so as to give
people on 6 the maximum amount of time to deal with this issue.

Best,
George