Thus spake Doug Rabson <[EMAIL PROTECTED]>: > > > Move the resolver code out to ibresolv.so, and link libc.so > > > against libresolv.so so that legacy applications are happy, as > > > long as they are compiled shared. Non-network apps can ignore > > > most of it. Internal use of some of the biggest chunks is > > > limited, so this should avoid dragging in a lot of it. > > > > We've been over this before. To make this work right, we need to make > > /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would > > solve the "oops!" and other foot shooting problems. > > Yes please. Our root filesystem space requirements are too high, IMHO.
Why is it absolutely necessary to dynamically link everything just to move the resolver out of libc? I'm all for doing the latter, but I think dynamically linking /bin and /sbin is a really bad idea, for several reasons: - If the single user mode runtime includes several shared libraries, you have several additional points of failure. - The use of shared libraries incurs a performance hit for programs like sh and echo, which should be fast. o Exec time is greatly increased because you have to map in the libraries. o The -fPIC code in the shared libraries is slower, particularly on the register-starved i386. o The VM system has to do more work when you have a sparse virtual memory map, which is what you get when you stick shared libraries in the middle of your address space. - Using shared libraries for trusted binaries like sh has negative consequences for security. For example, a `feature' of OpenSSH allows users to circumvent restrictions imposed using /sbin/nologin, provided that /sbin/nologin is dynamically linked. I don't think the disk space argument outweighs these problems. There are a few binaries in /sbin that are bigger than they ought to be, but it isn't as though /bin and /sbin occupy 500 MB. Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. I have run into problems with dynamic linking in the past. In one case, I couldn't log into a Linux machine because the administrator (who used bash, of course) had tcsh linked against a version of glibc that didn't exist on his system. I would really hate to see FreeBSD open itself up to the same kinds of foot-shooting opportunities just because of the resolver, or for the sake of a few dozen megs of disk space. Of all things, don't dynamically link my shell. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message