From owner-freebsd-hackers Fri Nov 15 17: 4:49 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 9F31437B401; Fri, 15 Nov 2002 17:04:46 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC4F43E6E; Fri, 15 Nov 2002 17:04:46 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 184122A88D; Fri, 15 Nov 2002 17:04:46 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Robert Watson Cc: Doug Rabson , "M. Warner Losh" , nate@root.org, kientzle@acm.org, hackers@FreeBSD.ORG Subject: Re: Shrinking /(s)bin: A Proposal In-Reply-To: Date: Fri, 15 Nov 2002 17:04:46 -0800 From: Peter Wemm Message-Id: <20021116010446.184122A88D@canning.wemm.org> 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 Robert Watson wrote: > > On Thu, 14 Nov 2002, Doug Rabson wrote: > > > > : I'm open to patches for building /[s]bin as dynamic. If you have > > > : time and can coordinate with lukem@netbsd.org to build the patch, I > > > : would appreciate it. > > > > > > % make NOSHARED=NO buildworld > > > > > > No patches necessary. We do this all the time at work, and it works > > > fabulously. I do this for disk based systems that have / and /usr on > > > the same file system too. > > > > To do it right for split root/usr installations requires a few patches > > though. The rtld and the libs required for /[s]bin need to move to / and > > compat symlinks created from /usr. A suitable crunchgen'ed binary for > > /recover would be useful too. > > I had some local patches that did a subset of this -- moved ld.so to /lib, > as well as installing shared libraries to /lib instead of /usr/lib for the > base system. I seem to recall I also had to tweak some defaults in ld.so > or rtld or the like, though. I agree that the right path to support fully > dynamic systems properly is to adopt the approach taken by NetBSD: provide > a decent /recover with crunchgen, etc. I do use fully dynamic stuff for > some local test boxes, makes upgrading libc code for development purposes > much easier, as well as supporting dlsym() for /sbin, which is very useful > in my environment. For what its worth: peter@daintree[4:55pm]/rescue-222# ls -sh@ dumpfs@ ipmon@ mount_portalfs@ rm@ [@ dumpon@ ipnat@ mount_std@ rmdir@ adjkerntz@ echo@ kenv@ mount_udf@ route@ atacontrol@ ed@ kill@ mount_umapfs@ routed@ badsect@ expr@ kldconfig@ mount_unionfs@ rtsol@ camcontrol@ fdisk@ kldload@ mv@ savecore@ cat@ fdisk_pc98@ kldstat@ natd@ setfacl@ ccdconfig@ fsck@ kldunload@ newfs@ sh@ chio@ fsck_ffs@ ldconfig@ newfs_msdos@ shutdown@ chmod@ fsck_msdosfs@ ln@ nfsiod@ slattach@ clri@ fsdb@ ls@ nos-tun@ sleep@ comcontrol@ fsirand@ mca@ pax@ spppcontrol@ conscontrol@ gbde@ md5@ ping@ startslip@ cp@ getfacl@ mdconfig@ ping6@ stty@ date@ gpt@ mdmfs@ ps@ swapon@ dd@ growfs@ mkdir@ pwd@ sync@ devd@ hostname@ mknod@ quotacheck@ sysctl@ devfs@ ifconfig@ mount@ raidctl@ test@ df@ init@ mount_cd9660@ rcorder@ tunefs@ dhclient@ ip6fw@ mount_ext2fs@ rcp@ umount@ disklabel@ ipf@ mount_msdosfs@ realpath@ dmesg@ ipfs@ mount_nfs@ reboot@ domainname@ ipfstat@ mount_ntfs@ rescue* dump@ ipfw@ mount_nullfs@ restore@ peter@daintree[4:55pm]/rescue-223# ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue* peter@daintree[4:55pm]/rescue-224# ./sh # ./ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue That's 2.7M to replace roughly 30M of /bin + /sbin. Warner quoted some numbers for a dynamic / case. I think we'd be looking in the order of a few megs of shared libs, plus about 2MB for /bin+/sbin. ie: a reduction from ~30M to somewhere in the area of about 7MB, and that includes the crunched static /rescue/*. This might actually fit on my SMP Pentium-90 box that was installed late 1995. :-) I didn't spend much time on the crunch stuff, I was mostly curious to see how it worked and what it could do. I was suprised at how easy it was to produce a binary. I haven't polished it up and haven't done any bmake glue. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message