Messages in this thread | | | Date | Fri, 19 Dec 1997 22:23:39 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: OFFTOPIC: binary modules, bad idea! |
| |
Date: Fri, 19 Dec 1997 17:50:02 -0600 From: Michael Elizabeth Chastain <mec@shout.net>
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
| |