On Wednesday 2009-11-04 20:49, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Wed, Nov 04, 2009 at 08:42:00PM CET:
>> What if a symbol has kept its name, yet changed in semantics?
>> The Linux Kernel has a number of features that address these
>> issues for itself,
>
>Can you expand on this, please? Pointers sufficient.
As far I understand it, a symbol's ABI (that is, a binary blob that
describes that) will be CRC32-checksummed and this checksum be recorded.
In current practice, it is implemented as fake symbols in one of the
intermediate output files that you can nm, and somewhat different
(different section nm does not care about?) in the final image:
$ nm vmlinux | grep __crc_
00000000881039d0 A __crc_zlib_inflate
^ there's your CRC
The same checksums are computed for calls the module makes.
$ modprobe --dump-modversions btrfs.ko|grep zlib
0x881039d0 zlib_inflate
Checksums are compared on loading a module and can be rejected if they
do not match -- or if they are simply not found.
Details of that should be in $linux/scripts/modversion.c or accompanying
.c files. I did not find all of it offhand.
Since the CRCs can be obtained at all, they _are_ actually used for
kernel rpm packages in openSUSE, with success. Especially when the ABI
does not change (minor updates such as 2.6.31 -> 2.6.31.5), things like
nvidia.ko can hang around unmodified for quite a while when it does not
use frequently-changing APIs. (Which btw is a side-effect of the legal
yadayada, not really an effort to avoid CRC mismatches).
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
