Re: Unfortunate dynamic linking for everything

On Tue, Nov 18, 2003, Robert Watson wrote:
> (2) Shells again, because they will be fork()d and exec()d frequently
>     during heavily scripted activities, such as system boot, periodic
>     events, large make jobs, etc.  And presumably the only shell of
>     interest is sh, although some of the supporting non-builtin binaries
>     may also be of interest. 

This is the only performance argument that truly seems compelling,
particularly since fork()/exec() performance for dynamic binaries
in FreeBSD really sucks as compared to Solaris and AIX (and
presumably other systems that have gone dynamic long ago).
I think this is mostly an aspect of the dynamic linker and the
lack of prebinding rather than performance problems in the VM system.

Most of the other arguments both for and against seem less
important.  The disk space argument that people have been giving
is particularly bogus given that disk capacity is increasing 60%
per year and the size of /bin isn't.  The NSS argument is only
valid because NSS was implemented specifically to require dlopen()
rather than a daemon, so that disadvantage is in no way
fundamental.

The best reason in my mind for going dynamic hasn't even been
mentioned much.  In a fully dynamic system, it is possible to
change kernel ABIs without breaking anything as long as the kernel
and libc are in sync.  Thus, we wouldn't have three versions of
statfs() and two versions of accept(), along with other cruft in
the kernel to support binaries going back to 4.2BSD.  The
compatX.Y libraries would suffice.  Also, developers would have
greater flexibility to extend or otherwise improve system
interfaces between minor releases.  Unfortunately, this would mean
giving up on ABI compatibility for static binaries entirely, so I
doubt it would fly anytime soon.  Moreover, the performance issues
we have with dynamic binaries now really are significant, at least
as of a few months ago.  (Maybe mdodd's prebinding work addresses
some of that.)

Dragonfly has addressed the same issue in a different, perhaps
more elegant way, wherein even static binaries have forward and
reverse ABI compatibility.  But it does still require the kernel
to mock up legacy fields in shared structures forever, and it
doesn't permit me to, for instance, take advantage of the fact
that mmap(), msync(), mprotect(), minherit(), madvise(), and
mincore() have essentially the same access checks and rewrite them
to use a common monitor.