Quoting Bean <bean12...@gmail.com>:
The biggest part is kern/misc.c, all are library function, many function in startup can also be moved to library.
It doesn't matter by itself. If the modules linked into the the kernel image use most functions in that library, there will be little of no saving.
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.
Actually, I'm also thinking about unifying the object format. We can write a program to convert from platform specific object file to an unified elf format, this would simplify the build process for system like osx, and the dynamic loader can be unified as well, which may save some code.
Yes, refactoring of the build system would be helpful. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
