From owner-freebsd-hackers Mon Nov 11 15:30:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E240837B401 for ; Mon, 11 Nov 2002 15:30:36 -0800 (PST) Received: from clover.kientzle.com (user-112uh9a.biz.mindspring.com [66.47.69.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 187B443E3B for ; Mon, 11 Nov 2002 15:30:36 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (c43 [66.47.69.43]) by clover.kientzle.com (8.11.3/8.11.3) with ESMTP id gABNUYE54459 for ; Mon, 11 Nov 2002 15:30:35 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3DD03D9A.6090805@acm.org> Date: Mon, 11 Nov 2002 15:30:34 -0800 From: Tim Kientzle Reply-To: kientzle@acm.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Shrinking /(s)bin: A Proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 /" 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