Date: Tue, 26 Nov 2002 17:50:26 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: arch@FreeBSD.org Subject: ABIs and 5.x branch: freeze kernel module ABI at 5.0 or 5.1? Message-ID: <Pine.NEB.3.96L.1021126174032.88614J-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Architectural question: in the past, we've attempted to maintain consistent ABIs over the lifetime of a branch, or to make use of versioned ABIs/APIs to provide compatibility. At the library level, this has involved caution and version bumps; at the system call level, via compatibility systems, and in the kernel, to a much lesser extent, by avoiding changes or only lengthening structures from the end (rather than in the middle). The ABI I'm primarily concerned with from the perspective of this e-mail is the in-kernel ABI for modules. My concern is primarily related to how to handle a potential ABI change in the mbuf structure, but more broadly, whether we should be providing guarantees about the ABI before 5.1. I'm particularly concerned that saying that we've frozen the network driver ABIs and hardware driver ABIs as of 5.0 until 6.0 rolls around will make it a lot harder for us to "land" 5.x into stability. As such, I think a reasonable strategy would be to avoid exactly that: rather than making guarantees about the ABI for 5.0, simply assert that the ABI for kernel drivers will not be frozen until 5.1, so vendors should be aware that they may have to rebuild their driver. We've already indicated that the 5.0 release will be for "early adopters"--I want to avoid having things stand in the way of kicking the 5.x branch into shape in as much as is possible. Any thoughts? Note: I really don't want to get into too broad a discussion of how we approach ABIs and versioning: I'd rather like to get a sense of whether or not we can assert that until 5.x is considered -STABLE, we can move the ABI. This isn't intended to set precedent, although I'd like to avoid foot-shooting if we can. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021126174032.88614J-100000>