Date: Mon, 11 Nov 2002 15:30:34 -0800 From: Tim Kientzle <kientzle@acm.org> To: hackers@freebsd.org Subject: Shrinking /(s)bin: A Proposal Message-ID: <3DD03D9A.6090805@acm.org>
next in thread | raw e-mail | index | archive | help
The possibility of dynamically linking /(s)bin seems
to recur pretty regularly. As libc continues to grow,
this idea seems worth revisiting. However, I've come up
with an alternative that might be worth considering.
For concreteness, consider /bin/mv, whose 400k (!!)
breaks down approximately as follows:
20k - core functionality
60k - stdio
320k - user_from_uid/group_from_gid
(used _only_ for the "Override <perm> <user>/<group>" prompt!)
The last item here includes yp* overhead, which
of course pulls in the resolver. Uck. I'd guess that
/bin and /sbin have at least 4MB of yp/resolver
duplication that could be trimmed (out of almost
30MB total), probably more.
I see several ways to address this:
1) make /bin/mv dynamic. Personally, I have
misgivings, but I understand NetBSD has done this.
2) Implement the resolver in the kernel.
3) Implement a daemon. Same idea as (2),
but in user space. Unlike (1), this can
be made pretty robust (e.g., 'mv' could
print "Override r-xr-xr-x for 1002/1002?"
if the daemon was unavailable). Response caching
could actually make this faster than (1).
4) Implement a command-line helper. A user_from_uid
binary could be run by /bin/mv as needed. This could
povide most of the benefits of a daemon with the
added advantage of on-demand loading; no memory is
required unless the service is actually needed.
5) Dump the corresponding functionality. In the case
of /bin/mv, this is worth considering (the warning
message becomes more cryptic, but no real functionality
is lost). It doesn't help much with /bin/ls, though.
I've started experimenting with the helper binary approach
(#4 above), and it seems pretty workable. Of course, a single
helper should handle user, group, and DNS lookups and do so in
a way that does not require re-running it for every lookup. I
can manage all of that without too much trouble.
This approach is robust (the client program can easily handle
service failure), reduces disk requirements significantly, and
potentially reduces memory requirements as well. It should ultimately
be possible to combine #3 and #4 in one executable, so that crippled
systems could run the from-disk binary to get access to the service, while
fully-functional systems would use the already-running daemon.
I suspect I can trim /bin/mv down to 40k or so using
this approach, with similar savings for many other utilities.
As I mentioned above, the total disk-space savings could
be considerable. This might also open the door to nsswitch
support for statically-linked binaries, though I'm no expert on
nsswitch.
Thoughts? As I said, I've started experimenting with
this approach, but my current efforts are hardly commit-quality.
If this is worth pursuing, I'm willing to do a lot of the work to make
it happen. (Specifically, I'm willing to implement the
helper binary and the glue logic and make the necessary
modifications to a half-dozen common utilities.)
Tim Kientzle
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?3DD03D9A.6090805>