lkml.org 
[lkml]   [1997]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.-----------------------------------------------------------


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.322 / U:1.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site