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

[Timo Teräs]

On 05/15/2010 05:39 AM, Rob Landley wrote:
> On Friday 14 May 2010 15:54:45 Timo Teräs wrote:
>> On 05/14/2010 09:34 PM, Denys Vlasenko wrote:
>>> 2010/5/14 Timo Teräs <timo.teras at iki.fi>:
>>>> 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:
>>>>
>>>> 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].
>>>
>>> This will break ld --gc-sections.
>>
>> I think ld handles --gc-sections properly if __start_sectionname symbol
>> is referenced. If not, using __attribute__((used)) should work.
> 
> Having a script create a human readable source file is something you could 
> explain to a middle school student with two weeks experience with C.  The 
> tools to do so are standardized by posix, and the versions busybox itself 
> produces support all necessary functionality.
>
> Having a magic linker function use vendor-specific extensions in a manner only 
> supported on certain toolchain versions is not just non-obvious, but you 
> yourself aren't sure off the top of your head how you'd have to go about 
> implementing it, and the explanation you just tried to give is full of non-
> obvious conditional requirements.

The above was just to explain that it is supported and well thought
mechanism, even if I don't happen to know all the details. Intention was
to point that --gc-section is not a problem. But as I already previously
agreed, portability is. And so is the sorting issue if we want to do
funny sorting or have multiple applets in one file.

> Given that the two techniqes produce equivalent results, this doesn't look 
> like a hard decision...

Yes, I've already agreed on this. Instead of flaming the idea, could we
move on and concentrate on getting the script done?