Date: Sat, 17 Jun 2006 13:02:31 +0900 From: gnn@freebsd.org To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org, Doug Barton <dougb@freebsd.org> Subject: Re: MFC of socket/protocol reference improvements Message-ID: <m2psh8ctuw.wl%gnn@neville-neil.com> In-Reply-To: <20060616202844.W742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> <20060616194310.M742@fledge.watson.org> <4493040D.7020707@FreeBSD.org> <20060616202844.W742@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2psh8ctuw.wl%gnn>