Michael, Denys, I'm sorry; it seems you don't understand. I wasn't referring to depending on gcc to do the linking for you, but rather doing it yourselves. I'm aware that you guys are used to depending on compilers, linkers and the kernel to do the hard work for you, but really, it's not that tough to do. There's no reason you would have to load init code just because the busybox process was started. You load that on demand, not by default. That way, you don't waste memory by loading init code that has nothing to do with the task busybox was launched to perform. I can foresee your complaints about the bloat this would introduce in determine what to load and when, but therein lies another challenge: how to minimize this. Arguing until you're blue in the face about bloat as a knee jerk reaction to requests for small features won't solve the problem for you, though; you'll have to put some thought into the root cause to fix this issue. The kernel developers did, and look at how much better it has worked out for them than it has for you.
Mike Dean On Thu, Mar 20, 2014 at 12:30 PM, Denys Vlasenko <[email protected]>wrote: > On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean <[email protected]> wrote: > > I'm curious. 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. > > People who are concerned with size just link statically. >
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
