Sure, this breaks binary compatibility. There is no boom, though,
because you can't load a module like this across kernel versions
anyway (unless you force it). In general, this exposes another issue
I have with the kernel API's: since they are generally completely
undocumented except by the kernel code itself, it is not always clear
what things are intended to be public interfaces, and what things are
intended to be private.
> As long as we are dealing with inline macros, it won't save you
> anything in the binary compatibility area at least.
You are correct that, as things stand, binary compatibility for kernel
modules is essentially nonexistent, and isn't really permitted by the
module version checking mechanisms anyway. However, interfaces that
are defined as macros may not always be defined that way, and the same
semantics can usually also be provided using function calls. So, an
API written this way (even if implemented with macros) could also be
implemented using function calls that would permit a higher degree of
binary compatibility.
To give a specific example, I implemented a "glue layer" for PCMCIA
that defined wrappers for most kernel facilities I used, so that I
could compile PCMCIA against a glue header, and compile the glue layer
against any kernel within a certain range, and the same PCMCIA modules
could then load across a fairly wide range of kernels. I did things
like implement all the spin lock macros as function calls, so that I
could also run the same modules against SMP and non-SMP kernels. It
has a performance cost, obviously, but it is nice to at least have the
option of doing things like this.
> David> The concept of deliberately implementing an API change so that
> David> it will break code, just so that people will notice it, with no
> David> other reason for the breakage, seems somewhat twisted to me.
>
> Well we can only disagree on that, it's one of the things that does
> that Linux gets cleaned up, while commercial vendors keep dragging
> piles of backwards compatibility cruft around. However it is also a
> good point that shows why code should be in the public tree.
Relying on the kernel source code as a primary means of communication
between key kernel developers is simply wrong.
-- Dave Hinds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/