From owner-freebsd-hackers Thu Mar 6 7:18:52 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01D5237B401 for ; Thu, 6 Mar 2003 07:18:51 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3487C43F85 for ; Thu, 6 Mar 2003 07:18:50 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.8/8.12.8) with ESMTP id h26FIkG1024297 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Mar 2003 10:18:46 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h26FIfW76521; Thu, 6 Mar 2003 10:18:41 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15975.26321.697361.250384@grasshopper.cs.duke.edu> Date: Thu, 6 Mar 2003 10:18:41 -0500 (EST) To: "M. Warner Losh" Cc: hackers@FreeBSD.ORG Subject: Re: Smarter kernel modules? In-Reply-To: <20030305.214439.00238175.imp@bsdimp.com> References: <20030306030852.GA1158@edgemaster.zombie.org> <20030305.214439.00238175.imp@bsdimp.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG M. Warner Losh writes: > In message: <20030306030852.GA1158@edgemaster.zombie.org> > Sean Kelly writes: > : Has anyone ever considered embedding some sort of identifier in kernel > : modules to keep them from being loaded with the wrong kernel? > > Actually, I was talking about this with Matt Dodd this morning... Whatever we do, lets NOT be anywhere near as fascist as linux. If we implement any kind of versioning, its got to be fine-grained enough that 3rd party binary modules will not get broken by an ABI change in an area of the kernel which they do not care about, or there needs to be a way for a module to opt-out. My company ships a binary driver ("ethernet" network, and character device) built on 4.1.1-R, and it has continued to work at least until 4.7-R. I'd like to see that same level of ABI stability throughout the 5-STABLE branch. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message