Ntpd config file support

Lauri Kasanen curaga at operamail.com
Sat Mar 22 10:47:36 UTC 2014


On Sat, Mar 22, 2014, at 1:57, Laurent Bercot wrote:
> On 21/03/2014 23:10, Cathey, Jim wrote:
> > The only thing BB would need would be to isolate initialization
> > into separate functions that would be grouped together by the
> > linker.  (And an associated link control file.)  The usual demand-paged
> > kernel will take care of the rest.
> 
> Yes, that would definitely be the right approach. However, it conflicts
> with code organization, and thus, maintainability: currently, the code is
> sharded by functionality, which is sane and sound - but the linker would
> need the code to be sharded by type, init or non-init, which is exactly
> orthogonal to functionality. I'm not up to date with latest linkers, but
> unless you can annotate functions inside a single .c, it means that you
> now need to split every single functionality into at least two .c files.

Slightly off tangent, but I remember reading a thesis on link time
optimization for the 2.4 linux kernel.

Among other things they managed to do was automatic recognition of init
code, and moving such to its own section. It was quite interesting tech,
no annotations needed; given the kernel already had some annotations,
the tech merged the newly found init code to the annotated one. It could
even detect parts that could not be annotated, because on some arch they
would be called more than once - if your arch didn't, into the init
section they went.

So this could be done entirely in the linker, no busybox code needed.

- Lauri

-- 
http://www.fastmail.fm - A fast, anti-spam email service.



More information about the busybox mailing list