Ntpd config file support

[Mike Dean]

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
<vda.linux at googlemail.com>wrote:

> On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean <mdean at emacinc.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140320/69ef2741/attachment.html>