Re: OFFTOPIC: binary modules, bad idea!

Michael Elizabeth Chastain (
Fri, 19 Dec 1997 23:30:07 -0600

Hello Ted,
Hello Kernel Hackers,

mec> /* resident.c */
mec> EXPORT_SYMBOL( foo );
mec> extern void foo( char * );
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

/* 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

> 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
"love without fear"