Re: idea: library support for grub2

[Bean]

>>> And with library,
>>> symlist.c is not needed as well, which saves another 3k.
>>
>> Perhaps I misunderstand something in your proposal.  I don't see how
>> introducing a library would eliminate symlist.c.
>>
>> We'll need a list of symbols for modules to use, whether those symbols are
>> in the kernel or in the library.  In fact, we'll need two lists instead of
>> one - one for the kernel and one for the library.
>>
>> We could use hashes instead of symbol names to make the symlist shorter (but
>> hashes won't compress as well, so it's not a sure win).  We can enumerate
>> the symbols - that would compress better.  Or we can resolve all kernel
>> symbols in the modules and eliminate the symlist.  But it's a completely
>> separate issue.
>
> The reason for symlist is to export function from kernel, but we can
> move the kernel to a module as well, therefore eliminating symlist
> altogether. With library, we can walk the module list (including
> kernel), and linked the unresolved function when generating core.img.

Hi,

Actually, perhaps the most space saving method is not to use module in
kernel. We could link kernel.img, modules and unresolved function into
a single image, this image only export one symbol, the firmware
structure, which is used to invoke platform specific function, such as
firmware.get_mmap, etc.

For external module, the function is loaded from library, although
this means there are two version of the function in memory, one static
linked in kernel, one dynamic loaded, but memory is generally not an
issue, it's the size of core.img that matters, and we don't want to
expand it  by adding the exported symbol table there.

There is also another usage for this method, now we can use two
different version of function with the same name. For example, we
could have two grub_printf, a simple version used in kernel, and a
full version in the library.

-- 
Bean