Re: OFFTOPIC: binary modules, bad idea!

Michael Elizabeth Chastain (
Fri, 19 Dec 1997 17:50:02 -0600

Hi Ted,
Hi kernel hackers,

Ted Ts'o writes:

> OK, so you're worried about the make dependencies problem, and not
> needlessly forcing a module to get recompiled when it doesn't need to
> be.

Yes. That's one of my concerns.

On a more conceptual level, consider the following code:

/* resident.c */
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!

This doesn't look like a problem if you compile everything at once.
But if you have .ver files from one version of the kernel, every module
built against those .ver files will use those type signatures, whatever
the module itself actually declares in its code or what is in system .h

The type signatures for module.o really should be derived from the
type information available to module.c at the time it is compiled.

> However, storing the information in a separate ELF section doesn't solve
> this, unless you actually have GCC generate the hash code. (If you store
> the hash code in slab.ver, you'd still have the same problem.) In fact,
> if you have GCC generate the hash code, it'd solve this problem whether
> the hash code is stored as part of the symbol name, or in a separate ELF
> section.

It would be really nice if GCC would generate a usable hash code or
some form of decorated symbol. But as you said, any solution has to
work with standard GCC.

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

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.

Michael Chastain
"love without fear"