Re: OFFTOPIC: binary modules, bad idea!

Theodore Y. Ts'o (tytso@MIT.EDU)
Sun, 21 Dec 1997 17:04:33 -0500

Date: Fri, 19 Dec 1997 23:30:07 -0600
From: Michael Elizabeth Chastain <>

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

That's not quite true. foo.ver is created when "make depend" is run,
not when resident.c is compiled.

If you unpack a new kernel tree, you have to run "make depend" or the
header files won't work at all. So that case is covered; the only time
that you might lose is if you patch foo.h, and you forget to run "make
depend". I think it's reasonable to ask kernel developers (who would be
the only one messing with a header file) to remember to run "make
depend" before compiling a module which depends of foo.ver.

> 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.

Yes, but they only get changed when a kernel hacker modifies them, and I
think it's fair to require a kernel hacker to remember to run "make

> 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.

Unfortunately, unless you actually use a make rule to only run genksyms
when it is necessary, the resulting speed hit when compiling modules (of
running genksyms all the time) is going to be quite fierce, I suspect.

- Ted