On a more conceptual level, consider the following code:
/* resident.c */
EXPORT_SYMBOL( foo );
extern void foo( char * );
/* module.c */
extern int foo( int );
Under the current scheme, module.o will use the type signature from the
declaration of foo() that is in resident.c, not module.c. insmod will
think these symbols match!
Anytime you don't put the function signature in a header file, you're
prone to losing. This applies whether you are using kernel modules or
not. If the function signature is a header file, you don't have this
problem, since if module.c is written to assume the wrong prototype,
this will be noticed at compile time.
In other words, this is a problem we would have if weren't using kernel
modules at all, but a library (containing resident.c) and a calling
application (containing module.c). The solution to this problem is
putting all of your interface prototypes in a header file --- so why
should we invent a separate, more complicated, solution for kernel
modules?
My idea is to run gcc first in the usual way, and then use 'ld -r'
to add in additional sections with the hash codes generated by
'genksyms'.
An alternate idea is to run 'genksyms' before compiling and using
the preprocessor to rename symbols, as is done now. The problem here
is that there is no IMPORT_SYMBOL to mark the symbols that need mangling.
Yes, but unless you're going to run genksyms for each compile, you'll
still have the dependency problem.
- Ted