From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 15:54:02 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 180FF16A4CF for ; Tue, 18 Nov 2003 15:54:02 -0800 (PST) Received: from dyson.jdyson.com (dsl-static-206-246-160-137.iquest.net [206.246.160.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F7E43F93 for ; Tue, 18 Nov 2003 15:54:01 -0800 (PST) (envelope-from toor@dyson.jdyson.com) Received: from dyson.jdyson.com (localhost [127.0.0.1]) by dyson.jdyson.com (8.12.8/8.9.3) with ESMTP id hAINs0XQ000781; Tue, 18 Nov 2003 18:54:00 -0500 (EST) (envelope-from toor@dyson.jdyson.com) Received: (from toor@localhost) by dyson.jdyson.com (8.12.8/8.12.8/Submit) id hAINrxHo000780; Tue, 18 Nov 2003 18:53:59 -0500 (EST) Message-Id: <200311182353.hAINrxHo000780@dyson.jdyson.com> In-Reply-To: <200311182319.hAINJ1Ae088335@khavrinen.lcs.mit.edu> from Garrett Wollman at "Nov 18, 2003 06:19:01 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Tue, 18 Nov 2003 18:53:59 -0500 (EST) From: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: dyson@iquest.net cc: current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dyson@iquest.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2003 23:54:02 -0000 Garrett Wollman said: > < > > If the object is to maximally 'share', > > The object, AIUI, is for ~username expansion to work in the shells > when the user stored somewhere defined by an external NSS module. I > don't believe that there is anything else in a (sane) shell that > cares. > It is a fallacy that EVERYTHING (e.g. libc) needs to be dynamically linked to support that feature. A single, self contained library that might even be sparse WRT memory isn't going to hurt much. A compromise that supports both a 'feature' and performance seems to be appropriate. Making everything shared (with the sparse allocation of .data, and .text somewhat) to implement a specific feature is certainly wasteful. All or nothing isn't the optimal answer here. John