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. So you need to have headers for the common data structures between two parts of the same functionality, and you want to isolate the interfaces so you make the headers private, etc. It's still manageable at this point, but the increase in complexity is major for a benefit that is probably marginal. (But a reasonably accurate estimation of this benefit would definitely be useful.)
(When using direct-mapped NOR flash, for example, you wouldn't care even then. With IDE-accessed flash, or rotating media, or a compressed filesystem, resident text pages would
For compressed filesystems, yes. For storage devices, it's not even certain: depending on the filesystem, newer Linux kernels have an execute-in-place option, and storage devices have a decent cache so it's not prohibitive. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
