Messages in this thread | | | Date | Tue, 22 Sep 2009 16:08:55 +0100 | From | Alan Jenkins <> | Subject | Re: [PATCH 2/4] kbuild: sort the list of symbols exported by the kernel (__ksymtab) |
| |
Sam Ravnborg wrote: > On Tue, Sep 22, 2009 at 02:38:36PM +0100, Alan Jenkins wrote: > >> modpost of vmlinux.o now extracts the ksymtab sections and outputs >> sorted versions of them as .tmp_exports.c. These sorted sections >> are linked into vmlinux and the original unsorted sections are >> discarded. >> >> This will allow modules to be loaded faster, resolving symbols using >> binary search, without any increase in the memory needed for the >> symbol tables. >> >> This does not affect the building of modules, so hopefully it won't >> affect compile times too much. >> > > I do not quite follow you here. > > With your patch: > > For vmlinux we define our symbols in sections > named *_sorted - but they are not sorted. > > We than create a small .c file that uses the original sections names > which is what is used in the final vmlinux. >
Actually it's intended to work the other way round.
EXPORT_SYMBOL() generates symbols in __ksymtab as usual. These get as far as vmlinux.o before I start changing anything.
My .c file then uses __EXPORT_SYMBOL_SORTED() to generate symbols in __ksymtab_sorted (or __ksymtab_gpl_sorted etc.), based on the symbols in vmlinux.o. So the _sorted sections _are_ sorted.
Finally, I changed the vmlinux linker script to effectively rename __ksymtab_sorted and discard the original unsorted __ksymtab.
I hope that clears that up.
> Could we replace the content of these sections rather than playing > games with the names? > > Sam >
Thinking about it, I guess I could avoid using new section names. I could change the vmlinux linker script to discard all __ksymtab sections, _except_ those which came from the file .tmp_exports.o. (And maybe rename .tmp_exports.o to .tmp_sorted_exports.o to make it more obvious).
That would avoid the need to add separate __EXPORT_SYMBOL_NAME() and __EXPORT_SYMBOL_SORTED(). OTOH, it means the linker script uses more features and is more tightly coupled to the build system. I.e. the script references a specific file.
I prefer my original method, but I can change it if you disagree :-).
Thanks! Alan
| |