Messages in this thread | | | Date | Sun, 21 Dec 1997 04:38:23 +0100 (CET) | From | Regis Duchesne <> | Subject | Re: Module versioning (was: Re: OFFTOPIC: binary modules, bad idea!) |
| |
> > 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.-----------------------------------------------------------
| |