Re: [PATCH] framework for building modules externally

[Christian Franke <Christian.Franke@t-online.de>]

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