mec> /* resident.c */
mec> EXPORT_SYMBOL( foo );
mec> extern void foo( char * );
mec>
mec> /* module.c */
mec> extern int foo( int );
ted> Anytime you don't put the function signature in a header file, you're
ted> prone to losing. This applies whether you are using kernel modules or
ted> not. If the function signature is a header file, you don't have this
ted> problem, since if module.c is written to assume the wrong prototype,
ted> this will be noticed at compile time.
This is true. I have to go to the more complicated, more realistic
example:
/* foo.h version N */
extern void foo( char * );
/* foo.h version N+1 */
extern int foo( int );
/* resident.c */
#include <linux/foo.h>
/* module.c */
#include <linux/foo.h>
The problem is that the type signature for 'foo' in module.c does not
come from foo.h. It comes from the foo.ver file, which was machine-
generated when resident.c was compiled. If the .ver file gets out of
sync with the .h file, then module.c will have the wrong type
signature.
> 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?
The problem is that the header file changes over time.
We already have a separate, more complicated solution for kernel modules,
CONFIG_MODVERSIONS. I am proposing to make this solution less complicated
by eliminating the .ver files. When module.c gets compiled, I want it
to get a type signature from the foo.h that it actually uses, not from
a .ver file that ultimately came from resident.c.
> Yes, but unless you're going to run genksyms for each compile, you'll
> still have the dependency problem.
I do plan to run genksyms on each compile of: a file that exports symbols
or a file that is compiled with -DMODULE.
Michael Chastain
<mailto:mec@shout.net>
"love without fear"