From owner-freebsd-arch Tue Nov 26 14:50:32 2002 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 C6CA437B401 for ; Tue, 26 Nov 2002 14:50:30 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4139943E4A for ; Tue, 26 Nov 2002 14:50:30 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAQMoQBF008956 for ; Tue, 26 Nov 2002 17:50:27 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 26 Nov 2002 17:50:26 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: ABIs and 5.x branch: freeze kernel module ABI at 5.0 or 5.1? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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