Ntpd config file support

[Ralf Friedl]

Mike Dean wrote:
> You mentioned earlier that code is never freed from memory.  If you're 
> this concerned with bloat, why don't you fix your problem of never 
> deallocating the init code instead of worrying about some small 
> feature like this?  The Linux kernel does this; that's why you see the 
> message about "Freeing xxKB of memory" late in the boot process.  The 
> freed memory is the memory that was used by the initialization code. 
>  This trick isn't limited to kernelspace.  You can dynamically link 
> libraries with init code, and you can unlink them at runtime as well. 
>  If you really want to reduce bloat, you can take a page from the 
> kernel devs and free all that init code after the binary is up and 
> running.  If you really are concerned with bloat, that is.
One important difference is that the kernel is loaded once and then runs 
for a long time, for different values of long.

Busybox implements a large number of programs, so in most systems it is 
likely that at least one of those will be executed regularly. Therefor, 
those pages you call init will have to be loaded again and again, so 
there would be no advantage in memory usage.
But you will have the disadvantages of the approach. It's more difficult 
to read and to maintain, as you have to write something like dlopen, 
dlsym, call init, dlclose instead of just init. For the same reason it 
also uses more memory, four function calls instead of one. The code in 
shared libraries tends to be larger because it has to be position 
independent. In addition, this would also increase the storage space 
required. The text and data segments are aligned to the page size. The 
shared library has it's own program header, relocation entries, names of 
the exported symbols. There are embedded devices running on 4MB flash 
that use busybox. Besides the work required for such an approach, the 
result would be actually worse.
You would also either require a dynamic linker to be present on the 
target machine, and the target to support dynamic libraries and dlopen. 
Or you would have to maintain two versions of each call to an init function.

What might be useful is labeling the functions and data structures as 
init_text and init_data, for the case where a device uses mostly long 
running processes. With help from the linker, these segments could be 
arranged together, and the kernel would just drop them when they are not 
used and memory is needed. It would not increase memory usage or storage 
requirements, and it doesn't have to be done all at once. And for 
targets that don't support it, it could just be left out, by defining 
the used macros as empty.