Messages in this thread | | | Date | Sat, 25 Sep 1999 09:31:55 -0700 | From | David Hinds <> | Subject | Re: [Q]: Linux and real device drivers |
| |
On Sat, Sep 25, 1999 at 11:44:39AM +0200, Jes Sorensen wrote: > > David> Sure, but the version checking on modules requires this anyway, > David> and doesn't distinguish between public and private interfaces. > David> Because all driver references to sk_buff structures are through > David> helper functions, we also have the option of arranging things > David> so that even layout changes would not require driver > David> recompiles. I think that's a good model to follow in designing > David> robust API's. > > Not entirely true, someone, for whatever reason, may do something > silly like: > > struct foo{ > struct sk_buff a; > struct sk_buff b; > } > > In their code, and boom.
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/
| |