* Why add stubs to network/ether.c?
@ 2013-07-02 20:27 Isaac
2013-07-02 21:47 ` Rich Felker
0 siblings, 1 reply; 2+ messages in thread
From: Isaac @ 2013-07-02 20:27 UTC (permalink / raw)
To: musl
Yes, I know this is a pretty small issue.
But commit fbcd8204 (add stubs for additional legacy ether.h functions)
is likely to bloat a full static busybox by a few bytes, for no additional
gain. Could stubs like these be kept separate from functional code?
(Applets that use ether_{aton,ntoa}(_r) include nameif, arping, zcip,
udhcpd, and ether-wake).
Thanks,
Isaac Dunham
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Why add stubs to network/ether.c?
2013-07-02 20:27 Why add stubs to network/ether.c? Isaac
@ 2013-07-02 21:47 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2013-07-02 21:47 UTC (permalink / raw)
To: musl
On Tue, Jul 02, 2013 at 01:27:20PM -0700, Isaac wrote:
> Yes, I know this is a pretty small issue.
> But commit fbcd8204 (add stubs for additional legacy ether.h functions)
> is likely to bloat a full static busybox by a few bytes, for no additional
> gain. Could stubs like these be kept separate from functional code?
Well the tradeoff is between making the .a file significantly larger
for each .o file we add, and making binaries a couple bytes larger.
I'm not sure what the right decision is here. We could try to assemble
lots of stubs together in one file I suppose. I'm open to ideas on
what ppl think is best.
Rich
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-07-02 21:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-02 20:27 Why add stubs to network/ether.c? Isaac
2013-07-02 21:47 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).