From owner-freebsd-arch@FreeBSD.ORG Sat Jun 17 06:57:59 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DBC16A479; Sat, 17 Jun 2006 06:57:59 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B3743D46; Sat, 17 Jun 2006 06:57:58 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5H6vQPZ039131; Fri, 16 Jun 2006 23:57:26 -0700 (PDT) Date: Sat, 17 Jun 2006 13:02:31 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson 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> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.5.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org, Doug Barton Subject: Re: MFC of socket/protocol reference improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 06:57:59 -0000 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