Date: Wed, 22 Apr 1998 18:01:46 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: benedict@echonyc.com (Snob Art Genre) Cc: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) Message-ID: <199804222301.SAA06796@dyson.iquest.net> In-Reply-To: <Pine.GSO.3.96.980422182145.19322B-100000@echonyc.com> from Snob Art Genre at "Apr 22, 98 06:25:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Snob Art Genre said: > On Wed, 22 Apr 1998, John S. Dyson wrote: > > > I'll scream terribly loudly if we even passingly consider making a > > shell shared!!! Shells are almost never advatageously made shared. > > Then why does our ports system build them incorrectly?! > Because I don't mess with the ports, and haven't done a very good job of making the above fact known. For maintenence, memory and speed reasons, one can seldom justify a shared shell. BTW, I use the ports extensively, but I tend to build and port the shells myself, probably for the issue that we are discussing. I haven't been watching this discussion carefully, but here are the costs of shared libs: fork() performance is slower. exec() performance is effectively slower (due to ld.so.) data and shared lib bss is packed much less effectively, and locality of reference, both at the sub-page level, and the page level is worse. Shared libs often require additional page table pages to map them. Here are the non-advantages: Shared libs don't help .text sharing, if a process has more than a few static occurances (shared .text works really well on our system.) Here are the advantages: Shared libs are great for processes where the libraries are large relative to the program size. Shared libs are great for processes that don't have many static or dynamic instances. My suggestions for programs that should probably not be linked shared under any circumstances: Make, cp, cat, ls, *sh, cc, daemons that fork, .... mail readers, any (small) program invoked by make, or repeatedly invoked by shell scripts. If the shared libs are on /usr, any program that needs to be able to work without /usr mounted. Programs where it is likely slightly advantageous to link shared: cc1, cc1plus, cpp, as, *roff, daemons that don't fork often, any X windows program (including those in any category), specialty programs that aren't used often... Programs where it is probably a toss-up: vi, *grep, other programs that don't fit the above criteria. Most of /usr/local, except for forking daemons. Reiterating, with clarification: More than 3-4 copies running at the same time: static Forks like a shell: static Must be able to run without shared libs: static If library CPU performance is critical: static Executes for a "long time", and doesn't fork often: shared Huge libraries: shared Not often used: shared -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804222301.SAA06796>