From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 14:25:59 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AB3437B401 for ; Thu, 17 Apr 2003 14:25:59 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BF143FBD for ; Thu, 17 Apr 2003 14:25:58 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h3HLPgv08708; Thu, 17 Apr 2003 14:25:42 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3E9F1C15.7080702@acm.org> Date: Thu, 17 Apr 2003 14:26:45 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: John Polstra Subject: Re: Going Dynamic (Was: HEADS UP: new NSS) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 21:25:59 -0000 John Polstra wrote: > Moving to a fully dynamically linked system sounds easier to me. > But in the past there has been strong opposition to the idea every > time it has been proposed. So far, the best argument in favor of a fully dynamic system has been: "Someday, someone might need dlopen() to implement NSS, PAM, or locales." I think there's a much stronger argument now: "Someone has already implemented a new NSS that requires dlopen()." As for the performance argument against dynamic linking, Luke Mewburn observed that after NetBSD switched to fully dynamic, suddenly the dynamic start-up code got a lot of attention , with wide-ranging benefits. Scott Long wrote: > Right, because everyone is deathly afraid of /usr/lib not being > available and nothing working, or ld.so getting corrupt and nothing > working, Nate Lawson and I had a discussion with Luke Mewburn of NetBSD about this. He outlined a strategy for dealing with exactly these issues. Two key points: 1) Move critical libraries from /usr/lib to /lib. This ensures that /bin, /sbin, etc, will all work during boot, for instance, before /usr is mounted. To date, people who wanted to experiment with fully dynamic had to keep /usr on the root partition. Note that static libs don't need to move, only a handful of dynamic libs need to be relocated (with compatibility symlinks from their old locations in /usr/lib, of course). 2) Build a separate set of statically-linked binaries for emergency use. I've already done this, and the patches are currently being reviewed. They add a /rescue directory which uses crunchgen to pack most of /bin, /sbin, and select other pieces into a nice small package. Gauranteed to work even if you hose ld.so. Note that the standard /bin and /sbin will continue to be used during boot and normal system operation. Since they're dynamically linked, dlopen() works and NSS, PAM, etc, can be used. If things go awry, then the /rescue directory will have fully static versions of standard utils that can be used to repair the system. The /rescue utils won't be able to fully use NSS or PAM, of course, but if you're booting single user to repair a hosed /usr partition, you probably don't really need NSS. ;-) I have Luke's full outline for transitioning to a dynamic system around here somewhere.... > If switching to a fully dynamically linked system is desired before > 6.0 then it needs to happen before 5.2. I'm not opposed to this. As I said, I've already done a chunk of work for this. If someone would like to help finish... Tim Kientzle