Re: Going Dynamic (Was: HEADS UP: new NSS)

From: Tim Kientzle <kientzle_at_acm.org>
Date: Fri, 18 Apr 2003 18:22:43 -0700
David Taylor wrote:
 > Hmm, but if /sbin/mount_ufs (say) is dynamically linked, and the libraries
 > are still in /usr, how do you mount /usr?

That's why certain critical shared libs
(e.g., libc.so) need to be moved to /lib.

 >>As I said, I've already done a chunk of work
 >>for this.  If someone would like to help finish...
 >
 > If there's a list of tasks that need to be done, I'd be willing to see
 > what I can do (although I'm going back to uni next week)...


Here are the remaining tasks that I know of:

1) Create /lib, move shared libraries.

     This involves working on bsd.lib.mk and a few related
     pieces so that certain libraries get installed
     differently:
       * shared lib into /lib
       * compatibility symlinks from /usr/lib -> /lib
       * static lib into /usr/lib

     Here's a list of libraries that I believe need to
     be moved:

     libc libcrypt libedit libkvm libl libm libtermcap
     libutil libalias libatm libcam libcurses libdevstat
     libipsec libipx libmd libncp libreadline libsbuf libsmb
     libufs libz

2) Update ld-elf.so.1

     I've not yet looked carefully at this.  This may need
     to be moved?  It will definitely need to have the
     default search path altered to look in /lib first.

If the above is done correctly, it should be possible to dynamically
link one of the standard utils (by adding NOSHARED=yes to the
Makefile for 'ed' or 'pax', for example), boot to single user and
have that utility work, even without /usr being mounted.

3) Set up a system-wide switch.  This may just mean
    setting a default for NOSHARED.  It may be necessary
    to visit specific Makefiles to override NOSHARED=no
    to force those utilities to be compiled static.
    (/sbin/init may require this.  A few other utils may
    also benefit.)

4) Boot-time safety issues.  Various tweaks to ensure that
    _something_ is possible even if the system gets screwed up.
    Not sure which of the following is best:
     a) Kernel automatically runs /rescue/init if /sbin/init fails
        too quickly.
     b) Prompt user for an alternate init if /sbin/init fails.
     c) Have /sbin/init remain static, alter it to prompt
        for /rescue/sh in single-user mode (always? sometimes?).
    I'm leaning towards some variant of (c), but I'm not sure
    what all the issues are here.

Tim Kientzle
Received on Fri Apr 18 2003 - 16:22:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC