Date: Fri, 15 Nov 2002 16:25:50 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: hackers@freebsd.org Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <200211160025.gAG0PoBu001329@apollo.backplane.com> References: <20021115111704.B2812-100000@beagle.fokus.gmd.de> <200211151029.gAFATBmQ008076@apollo.backplane.com> <20021115.162654.106394440.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This should really be on hackers, not cvs-committers. I have
redirected the Cc.
:I don't think that a mini-c will help at all. /bin can be scrunched
:down to 500k and sbin to 605k on 4.5 and the system will still boot.
:A full install is only 2842k when sbin/bin are dynamically linked. A
:full static install is 15302k. mini-c would help in the static case,
:but not at all in the dynamic case. If you have to have libc, et al,
:on /, then the libraries used by sbin/bin are 1604k in size, which
:cuts into your savings down to only 10M. A mini-c dynamic would help
:a little in this case, but it can't help by more than 500k, which is
:the size of libc. When both / and /usr are on the same partition,
:your savings is 12M. I've booted 6M 4.5 systems, including kernel and
:all binaries to boot as well as a few things like telnetd, etc.
:
:Warner
Well, I certainly agree that the direct benefits in the dynamic case
are fairly minimal.
The benefit that I see in the dynamic case is simply that it
gives us an alternative libc whos bloat can be managed far more
effectively then the bloat in libc. You only have to see how
libc has grown over the years to know that the bloat-over-time
issue is fairly significant. A libminic gives us a tool to help
deal with it. libc.so.4 was 574K. libc.so.5 is 832K. The benefit
of having a more controlled environment for / is clear. The
libminic.so is 820K but with some care I can pare it down to 500K.
Regardless of you or I, there are certainly embedded developers
out there who can benefit from a bloat-controlled dynamic libminic.
The benefits in the static case are clearer. For a statically linked
[s]bin I expect we will be able to cut the storage overhead almost
in half with a little care (and no terrible hacks), and there
are also major benefits to using static binaries in regards to
memory footprints (static binaries do not dirty as many data pages
as dynamic binaries), and startup overhead. These benefits are
primarily targeted to smaller programs since larger programs tend
to swamp the benefit out. While it is true that the dynamic case
will win hands down over static for /bin and /sbin, not all developers
are willing to go to a dynamic / (I personally would rather stick
with a static /, especially for programs like 'csh', 'sh', and 'getty').
I am also sure that there are developers who simply want to run
a single program on boot in a turnkey environment.. hell, I've
done that occassionally myself (replace init). If there are no
other programs, then static is the way to go and you wind up eating
less space then if you had been dynamic.
So, the jist of all of this is that I see a significant benefit for
both a dynamic-linked libc for /, and for a static or dynamic linked
libminic for /. The option in my first proposed patch set are
intended to allow all four combinations of static/dynamic, libc/libminic
for /.
-
There is also another possibility which I hesitate to bring up but
which I have used in nearly every embedded project I've ever done
(with custom operating systems, not with FreeBSD), and that is
the fact that we have a perfectly good mini C library built into
the kernel image for many common functions like bcopy, strcpu.
*printf(), etc. If we really want to save space we could make
an API available and mmap() the library from the kernel image
directly.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211160025.gAG0PoBu001329>