Date: Thu, 6 Mar 2003 18:52:26 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: hackers@FreeBSD.ORG, smkelly@zombie.org Subject: Re: Smarter kernel modules? Message-ID: <20030306075225.GB93350@cirb503493.alcatel.com.au> In-Reply-To: <20030305.215901.36360277.imp@bsdimp.com> References: <20030305.215901.36360277.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030306075225.GB93350>