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

Rob Landley rob at landley.net
Fri May 14 09:33:09 UTC 2010


On Friday 14 May 2010 02:25:42 Timo Teräs wrote:
> 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].

Actually we have vague plans to generate that in a similar manner.

Linker magic is a bit non-obvious for my tastes, and also won't be able to 
automatically alphebetize them and thus lend itself to a binary search, 
reducing launch latencies in scripts... 

> 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.

With pcc and llvm getting more interesting, I'd rather _not_ add anything gnu 
specific.  (One of the things I like about busybox is the ability to wean a 
system off GNU insanity.)

> 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?

Script to autogenerate applet.h is what I did for toybox back in 2007.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the busybox mailing list