Re: OFFTOPIC: binary modules, bad idea!

Linux-Kernel Mail Account (kernel@whitestar.soark.net)
Sat, 20 Dec 1997 07:47:50 -0500 (EST)


I'm not sure if I'm reading this right but, would a mv_if_changed not do
the job? Ignoring the date and running a diff on the file...
*shrugs*

Zephaniah E, Hull

On Sat, 20 Dec 1997, Martin von Loewis wrote:

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