From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 18:53:34 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 CF61716A47B; Fri, 16 Jun 2006 18:53:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63CF843D45; Fri, 16 Jun 2006 18:53:34 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C658646B80; Fri, 16 Jun 2006 14:53:33 -0400 (EDT) Date: Fri, 16 Jun 2006 19:53:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Barton In-Reply-To: <4492FB95.9050606@FreeBSD.org> Message-ID: <20060616194310.M742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org 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: Fri, 16 Jun 2006 18:53:34 -0000 On Fri, 16 Jun 2006, Doug Barton wrote: > I'm opposed to this kind of change on principle. The issue of subtle but > incompatible changes to the API within a major release branch has come up > before as one of the reasons that vendors find it difficult/uninteresting to > support FreeBSD. With our new shorter release cycles, I think we need to > draw a line in the sand and declare unambiguously that the APIs will NOT > change within a release, and then live (and learn) with the consequences. > > If these (or any other) changes become so compelling that we feel the > userbase needs to have them ASAP, I would suggest that this would be > justification to move up the release cycle for 7.x, not to break faith in > 6.x. Understand that this is a KPI -- kernel programm interface, and not an API. No applications will be affected by this change, since the sockets API and protocol management APIs for applications are untouched. In general, we don't maintain KPI compatibility in a branch except for some specific kernel interfaces, such as device driver interfaces, which are untouched by the proposed changes. In fact, the third party infiniband stack and the SCTP stack (which will be merged soon) are the first cases I know of where significant third party code bases program against this kernel interface on FreeBSD, other (historically) than early KAME development. And both the SCTP stack and KAME stack required changes to the same KPI changed by these patches, so that's really the Infiniband stack is the only one instance we know of, and is used by a vendor that already extensively modifies the kernel in ways that will be affected by even very minor changes within other parts of the kernel. So I'm not just looking for objection on principle, I'm looking for objection based on practice: do we know of third parties extending the kernel with this KPI who distribute their work and will be affected by this in ways that make it difficult for them to maintain their component? Remember that if they compile their module against the updated kernel, they will get warnings indicating the KPI changes have taken place, since the prototypes of the affected protosw entries will change. The question is really whether we want to rule out any further TCP and socket structural improvements for RELENG_6 based on kernel modules that only hypothetically exist or not. If we can show they exist, then that's another issue, but it requires organizations to have written entire protocol stacks from the ground up, which is (one presumes) relatively rare, and to a KPI that has in the past changed frequently (not the protosw interfaces, but certainly other aspects of socket behavior that are immediately relevant). Also as an FYI: this does not affect consumers of sockets in the kernel, such as distributed file systems, only implementors of protocols themselves, such as TCP/IP, AppleTalk, IPX/SPX, etc. Robert N M Watson Computer Laboratory University of Cambridge