Re: OFFTOPIC: binary modules, bad idea!

Martin von Loewis (martin@mira.isdn.cs.tu-berlin.de)
Sat, 20 Dec 1997 12:54:52 +0100


> Right now, if drivers/net/foo.o has an external symbol for kmalloc, it
> depends on include/modules/slab.ver, which is generated from mm/slab.c.
> So changes in mm/slab.c cause all modules to be rebuilt because type
> information from mm/slab.c goes into all module files.

I believe this is a make problem. If slab.c or one of its header files is
changed, slab.ver is remade, as the symbol signatures might have changed.

In most cases, they did not change. Still, slab.ver is overwritten. A
smarter mechanism now might check whether slab.ver actually changed,
and overwrite it only in that case. This does not help much, as slab.ver
in turn depends on a the sources used to generate it. Next time, make
finds that slab.ver is not up-to-date, and remakes it. Since the contents
still did not change, it will be remade every time.

I once tried solving this with time stamp files, but could not figure
out how it should work. In particular, what should depend on the time
stamp files? If I put them everywhere the .ver files are now, I don't
gain anything: whenever the time stamps change, everything is remade.
If I leave the ver files where they are, make does not even consider
remaking the time stamp files. If I somehow tell make to remake the
time-stamp files, but don't mention that the ver files might change
in the process, make will not reconsider dependants of the ver files.

One solution would be to better support time stamp files in make. This
is not only a Linux problem.

If changing make is not an option, it seems that the versions have to
be put into some other place. An ELF section sounds like a good idea,
then.

Regards,
Martin