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.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
