Date: Fri, 18 Apr 2003 18:22:43 -0700 From: Tim Kientzle <kientzle@acm.org> To: David Taylor <davidt@yadt.co.uk> Cc: current@freebsd.org Subject: Re: Going Dynamic (Was: HEADS UP: new NSS) Message-ID: <3EA0A4E3.6090801@acm.org> References: <20030417141133.GA4155@madman.celabo.org> <20030417144449.GA4530@madman.celabo.org> <200304171535.h3HFZEFs094589@strings.polstra.com> <20030418014500.B94094@iclub.nsu.ru> <200304171944.h3HJi1jK095151@strings.polstra.com> <3E9F0A28.8030906@btc.adaptec.com> <3E9F1C15.7080702@acm.org> <20030417221622.GA18079@gattaca.yadt.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA0A4E3.6090801>