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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
