On Sat, Jul 4, 2009 at 10:27 PM, Pavel Roskin<[email protected]> wrote: > Quoting Bean <[email protected]>: > >> 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. >
Many string and char function are rarely used, and the unicode function is used only by some fs. >> 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. -- Bean _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
