Date: Fri, 16 Jun 2006 19:53:33 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements Message-ID: <20060616194310.M742@fledge.watson.org> In-Reply-To: <4492FB95.9050606@FreeBSD.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060616194310.M742>