> > The major problem with module versionning is not that much related to the
> > technology (ELF trickery or preprocessor solution with .ver file). The
> > problem is that genksyms does not know where to stop. This is a kernel
> > header issue. Let me explain with an example.
>
> Is *this* the real issue? I would imagine that the scenario presented
> rarely happens; i.e. if you change a structure, you do break the modules
> that call functions expecting pointers to these structures.
As far as I know from my own experience with kernel design (umsdos), most
kernel structure are often tricky to manipulate (access count, locking,
mutex, whatever) so most operation are done using helper functions. Also,
a lot of kernel structure are making reference to other structure using
pointers.
> It would be interesting to analyze what symbol versions changed during
> the life of Linux 2.0, and what modules are affected by those.
>
> If there are some functions that frequently break even though the
> parameters are meant to be opaque, then the parameters should be
> changed to actually be opaque (say, void* or the like).
I was thinking that genksyms could be hacked to produce some nice report
showing how the CRC of each symbol/function is computed. I suspect that
just by looking at this report many people will be surprised by the fact
that most kernel opaque structure are effectivly affecting the CRC even if
they are never directly access by module code.
--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Linuxconf: The ultimate administration system for Linux.
see http://www.solucorp.qc.ca/linuxconf
new developments: remote GUI admin, multiple machines admin