From owner-freebsd-hackers Wed Mar 5 23:52:42 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 42F3437B401 for ; Wed, 5 Mar 2003 23:52:40 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8530743F85 for ; Wed, 5 Mar 2003 23:52:38 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h267qSLZ093967; Thu, 6 Mar 2003 18:52:28 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h267qQ8j093966; Thu, 6 Mar 2003 18:52:26 +1100 (EST) Date: Thu, 6 Mar 2003 18:52:26 +1100 From: Peter Jeremy To: "M. Warner Losh" Cc: hackers@FreeBSD.ORG, smkelly@zombie.org Subject: Re: Smarter kernel modules? Message-ID: <20030306075225.GB93350@cirb503493.alcatel.com.au> References: <20030305.215901.36360277.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030305.215901.36360277.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote: >Here's a simple patch. However, it is a total suck-ass kludge (and >that's being generous). The ABI isn't THE ABI, but rather a >collection of ABIs. These ABIs change slowly and there is a certain >range that work together. I think you're being overly harsh. It strikes me as a very simple way to provide at least a coarse level of versioning. (The other downside is that the error messages may be too cryptic for a non-developer to understand). The biggest downside is that (as you point out) it is a single magic number to represent the version of all of the kernel interfaces. What you really want is a version number associated with each "interface" - then only modules that use that particular interface are affected. As for actually implementing this: How about a combination of C++ name-mangling and "namespace.h" from our libc? Change all our external kernel symbols so that "foo" shows up as "foo__N" (where N starts at 1 and increments every time something about foo's definition changes). Near the top of the include file containing the symbol declaration you add a "#define foo foo__N" so code doesn't see the version number. Benefits: - Versioning tied to specific symbol definition - no need to have a coarse "bump the version when things get too incompatible". You can bump the version of a symbol when it changes at all. - Only modules that actually reference a changed symbol fail. - Versioning uses exact matches so the version number could go backwards if an API change gets backed out (eg the recent malloc M_WAITOK changes) - old modules would start to work again. Of course you've got to remember to skip that number on the next increment. - Automatically detects naughty code that doesn't include the appropriate headers. - The kernel's dynamic loader could be taught to provide legible error messages (eg "foo.ko: Needs malloc version 123 found 126") - Potentially, shim modules could be created to supply legacy interfaces - at least for functions. (eg for the aborted malloc() changes, a shim function could have mapped between the different flags meanings). The kernel loader could even automatically look for shim .ko's. Disadvantages: - Needs grunt-work to write the #defines - Kernel symbols reported by nm(1) look strange (unless we patch binutils to understand our versioning scheme). - May present problems to '##' built symbols. Comments? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message