Robert Millan wrote:
On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
Alternative: Export a symbol describing the ABI version in kernel
("grub_abi_3_14").
That requires more bytes than a 32-bit integer.
The symbol value does not matter, the symbol name string provides enough
space to describe any version.
GCC apparently uses a similar method ("_gcc/gxx_personality_*") to
ensure that the correct libgcc is linked.
Access this symbol in each module (this can be hidden
in GRUB_MOD_INIT).
And this adds code in every module, but for non-external modules we already
have reassurance that their abi is consistent (users should never bypass
grub-install; if they do, it's likely going to break for them anyway).
I understand there's a minor benefit for programmers of external modules,
but both things are at the expense of extra size to kernel and core.img
modules. External modules will only provide non-essential functionality, so
it's not a problem they have to check the ABI IMHO.
I agree, such a check is not necessary for the non-external modules.
But, exporting one extra "grub_abi_VERSION" symbol would only require
one entry in the kernel symbol table and no other code.
Then, a module author has the option to check the ABI version by
importing this symbol
(possibly by simply adding '-u grub_abi_VERSION' to ld command)
--
Christian Franke
PS: The current use of __FILE__ may also add extra unexpected size: For
packaging, configure is often run outside of $srcdir with a absolute
path name. This may result in long __FILE__ strings, like
/home/maintainer/packaging/grub/tmp/grub-1.96+20081105-1/src/grub-1.96/kern/disk.c
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
