From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 17:25:21 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 E92DB16A4CF; Tue, 18 Nov 2003 17:25:21 -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 82D2443FD7; Tue, 18 Nov 2003 17:25:20 -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 hAJ1PIXQ000970; Tue, 18 Nov 2003 20:25:18 -0500 (EST) (envelope-from toor@dyson.jdyson.com) Received: (from toor@localhost) by dyson.jdyson.com (8.12.8/8.12.8/Submit) id hAJ1PIPN000969; Tue, 18 Nov 2003 20:25:18 -0500 (EST) Message-Id: <200311190125.hAJ1PIPN000969@dyson.jdyson.com> In-Reply-To: <20031118175434.A35215@pooker.samsco.home> from Scott Long at "Nov 18, 2003 06:09:31 pm" To: scottl@freebsd.org (Scott Long) Date: Tue, 18 Nov 2003 20:25:18 -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 cc: "M. Warner Losh" 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: Wed, 19 Nov 2003 01:25:22 -0000 Scott Long said: > On Tue, 18 Nov 2003 dyson@iquest.net wrote: > > The cool thing about properly implemented shared libs is that not everything > > has to be shared. Even the kernel supports runtime loading/addition > > of modules, and the NSS sounds like a good candidate for a library > > feature. Burdening everything with the sparse .data associated with > > libc seems to be a waste (but, perhaps the performance that was carefully > > crafted into the codebase is no longer important?) Really -- it is > > possible that performance isnt' important anymore, and fully accepting > > the ongoing loss of performance for features (without careful tradeoffs) > > might be an appropriate strategy. (In the case of the NSS stuff, it > > shouldn't require everything to be built dynamic.) > > Unfortunately, our dynamic linker prevents dlopen() and friends from > working in a static binary. There was some talk about having NSS > lookups happen through a proxy process, but our implementation just > plain wasn't done that way, and no one has stepped forward with > alternate code. > It seems like the defect is with the old limitation on the dlopen things then. (That limitation has been operative for years.) Making that decision 6months ago (or whenever the decision was made) seems to result in sidestepping the best solution (esp when 6months is alot of time to fix such limitations.) Again, I cannot take the responsibility, and mostly trying to keep 'improvements' from undoing previous work. I am worried (really) that there'll be a progressive loss of performance in order to gain features that could have been implemented with less impact. There was ALOT of work in trying to make FreeBSD very performant, and throwing that away with incrementalism seems to be wasteful. I am NOT meaning to negatively criticize, because that is quite seductive, and I am NOT suggesting that FreeBSD should have the Plan9 mimalist ethic. :-). Favorite 'tricky' features will come and go -- but basic system performance gets harder and hard to recover as time goes on!!! I guess that all OSes have a size/performance curve where they get bigger and fatter, SOMETIMES (not always) losing previous attributes for new features. Just don't let the performance loss go too far. IMO, I wouldn't have supported everything be built shared if there was a POTENTIAL mitigating solution of a proper dlopen implementation. DG would likely have had a 'fit.' Perhaps there should be a FreeBSD performance (and footprint) responsibility officer before it becomes too bloated to recover? :-). John