Ntpd config file support

[Mike Dean]

In the 2.6 and 3.x kernels, you annotate your init functions with the
__init macro, like so:

static int __init myinit( void )  { return 0; }

No more hoops are needed, but no fewer.  It's simple, and it works well for
the kernel.


Mike Dean

mdean at emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Sat, Mar 22, 2014 at 5:47 AM, Lauri Kasanen <curaga at operamail.com> wrote:

> 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.
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140324/0a44ee62/attachment.html>