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 [email protected] http://lists.busybox.net/mailman/listinfo/busybox
