MFC of socket/protocol reference improvements

[Robert Watson]

On Fri, 16 Jun 2006, Doug Barton wrote:

> That said however, I reject your hypothesis that a third party developer who 
> is depending on the status quo has to make themselves known before you're 
> willing to reconsider changing things in RELENG_6. There are any number of 
> reasons why this might be impossible or undesirable, not the least of which 
> is that no one from that vendor is subscribed to -arch.
>
> On a more fundamental level, what I'm asking for is a clear bright line, and 
> what you're saying is that it's ok for the line to be fuzzy, where some 
> things can always be changed because they don't affect anyone we know about, 
> other things can sometimes be changed if the pain is minimal, etc. I fully 
> concede that from a developer standpoint, you might be right, and you're in 
> a much better position than I to make that call. However from a business 
> standpoint (and I am forced to where my businessman hat more than my 
> developer hat nowadays, c'est la vie), clear bright lines are good, and 
> fuzzy lines that depend on the (perceived) whims of people I don't know and 
> don't have any authority over are bad.

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.

Robert N M Watson
Computer Laboratory
University of Cambridge