Re: Module versioning (was: Re: OFFTOPIC: binary modules, bad idea!)

Regis Duchesne (regis@via.ecp.fr)
Sun, 21 Dec 1997 04:38:23 +0100 (CET)

> > 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.
Yes, this is the real issue.

> It would be interesting to analyze what symbol versions changed during
> the life of Linux 2.0, and what modules are affected by those.
Martin, I have tried this with the NTFS module between 2.1.71 and 2.1.72
and _a lot_ of symbol versions changed.

> 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).
Good idea.
Advantage : we can keep inlined functions (and fast code :) like this

#ifdef CONFIG_MODULE_LONG_LIVE
inline void foo_add(void *p)
#else
inline void foo_add(struct foo *p)
#endif
{
.
.
}

Drawback : Compiling the module is not type-safe anymore :(

void modfoo (struct foo *p)
{
char *blah;
.
.
foo_add(blah);
}

PS : Jacques, my other approach (make a smarter genksyms) was stupid...

Regis "HPReg" Duchesne - Engineering Student at ***** ******** *****
www http://www.via.ecp.fr/~regis/
(O o) I use Linux & 3Com (1135 KB/s over 10Mb/s ethernet)
--.oOO--(_)--OOo.-----------------------------------------------------------