Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: John Franklin <franklin@elfie.org>
List: current-users
Date: 08/27/2002 11:59:14
On Mon, Aug 26, 2002 at 11:13:36AM -0700, Jason R Thorpe wrote:
> On Mon, Aug 26, 2002 at 02:06:10PM -0400, Andrew Cagney wrote:
> 
>  > I assume the saving is so that a NetBSD root file system can better fit 
>  > onto things like flash?  Should this and other such tricks (triming 
>  > libc, ...) be left those people?
> 
> Actually, one of the biggest motivations is so that dlopen() is available
> to these programs (think "locale").

You know, I just can't get over the feeling that that's not really the
case.  Yes, pluggable anything requires dlopen().  OTOH, the locale text
can be stored in ELF segments with names like .en_US or .fr_FR or
.zh_CN.  Locale handling code can just as easily be statically linked to
the program.  

Obviously, this can really bloat the apps, especially for ASCII or
Latin-1 countries.  So, /etc/mk.conf variables can advise the linker as
to what locale support to include.

The two major problems with shlib /bin and /sbin are:

1. shlib performance is slow slow slow.  As Jason mentioned before, this
is something that should be worked on.  I'd even go so far to say it
should be a priority.  Anything that can improve system performance
across the board -- especially across all ports -- should be a priority.
Until then, slower ports, like VAX and mac68k, definitely benefit from
at least the option to keep them static.  

Shared libraries should make system performance faster anyway.  Namei
cache hits handle lookup()s.  The most common code pages are already
loaded, no slow disk fetch needed.  One page of physical memory supports
several programs, meaning more memory is available for the programs.
So, what's the problem?

2. Should something go wrong, three (or more) files are needed to
execute programs: the program, libc.so and ld.so.  If any of these are
are out of sync with each other, or are corrupt we have to depend on the
/rescue versions of some programs to save you.  At that point, you're
probably better off with a true altroot or a rescue floppy/CD.  The
number of failure modes with shlibs are much higher.  And as one who's
had to deal with a Linux box with scragged libc, I was proud to be a
NetBSD supporter.  (It was actually libc was out of sync with
libnsswitch, which prevented things from dynamically linking.)

jf
-- 
John Franklin
franklin@elfie.org
ICBM: 3543'56"N 7853'27"W