[PATCH] make it possible to keep Config/Kbuild snippets in *.c files

[Timo Teräs]

On 05/14/2010 09:22 AM, Rob Landley wrote:
> On Sunday 09 May 2010 09:19:58 Denys Vlasenko wrote:
>> On Sunday 09 May 2010 07:31, Rob Landley wrote:
>>> I note that CONFIG_APPNAME += appname.o is the common case, which could
>>> presumably be generated automatically for 90% of the commands.  (You only
>>> really need to specify something like this when there's more than one .o
>>> file, or if the .o file is a different name...)
>>
>> Yes, de do have those 10%
>>
>>> Again, this looks like a default case.  If you're going to do this for
>>> more than one directory, possibly this should be emitted by the script
>>> rather than appended to, and only non-default stuff should go in here.
>>>
>>> The Config.src file had a reason to exist because it was naming the menu,
>>> but this one isn't actually doing anything.
>>
>> applets/ and archival/ have non-trivial Kbuilds
>>
>>> Also, since these files are generated you don't really need one per
>>> directory. You could just make one big one.  (Which brings us back to the
>>> generated directory, mentioned earlier.)
>>>
>>> Still, that sort of thing could easily be done in stages.  (Cleanup on
>>> top of cleanup, this is fine for now...)  The important thing is getting
>>> the syntax that goes into the .c files right, so that conversion doesn't
>>> have to be redone.
>>
>> Right.

While at it, we could get rid of include/applets.h too. One very nice
way would be to use linker section. You can use gcc __attribute__
section("sectionname") [1] to put the applet definitions to separate
memory area. It is after that possible to iterate over the structures
in that special section using __start_sectionname and __stop_sectionname
symbols which are autocreated [2]. This is also roughly how Linux kernel
initcalls work [3].

Now it appears that the applets need to be sorted for binary search.
I haven't actually tried this, but I think linker could probably do the
job. Normally, the section symbols get the order the object files
are given to ld, but it is also possible to have the linker sort the
filenames alphabetically [4, 5]. This of course assumes that each applet
is in it's own object file, and that the object file name sorting order
is the same as applet name sorting order.

This obviously depends on GCC specific attribute, and GNU LD specific
linking. I'm not sure how well this is supported by other compilers.

Would this be useful approach for busybox? Or do we want to be more
generic and possibly just create some scripts to autogenerate the
applet.h? Other ideas?

Just a thought.

Cheers,
 Timo

[1] http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Variable-Attributes.html
[2] http://www.airs.com/blog/archives/56
[3] http://kernelnewbies.org/InitcallMechanism/HowItWorks
[4] http://www.delorie.com/gnu/docs/binutils/ld_23.html
[5] http://www.delorie.com/gnu/docs/binutils/ld_24.html