From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 18:09:38 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 F387B37B487 for ; Thu, 17 Apr 2003 18:09:37 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2257043FAF for ; Thu, 17 Apr 2003 18:09:37 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id A3B8C5F; Thu, 17 Apr 2003 20:09:36 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id F250678C66; Thu, 17 Apr 2003 20:09:35 -0500 (CDT) Date: Thu, 17 Apr 2003 20:09:35 -0500 From: "Jacques A. Vidrine" To: Garrett Wollman Message-ID: <20030418010935.GD4001@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Garrett Wollman , Max Khon , freebsd-current@freebsd.org References: <20030417141133.GA4155@madman.celabo.org> <1050590195.76150.8.camel@owen1492.uf.corelab.com> <20030417144449.GA4530@madman.celabo.org> <20030418002346.A91615@iclub.nsu.ru> <20030417173607.GA2682@madman.celabo.org> <200304172044.h3HKi52w032010@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304172044.h3HKi52w032010@khavrinen.lcs.mit.edu> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: new NSS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 01:09:38 -0000 On Thu, Apr 17, 2003 at 04:44:05PM -0400, Garrett Wollman wrote: > One possible way around this is to add an external resolver (like > Solaris's `nscd'); the static library can use a stub routine to call > the resolver if possible (i.e., the machine is running multiuser), and > then fall back to the built-in databases if this fails. This way, > only the users who needed loadable NSS modules would pay the cost. Indeed, even in a completely dynamically-linked system, an nscd has some value. When we do get one, it would likely be optional, however. Some NSS modules already do their own caching; and also sometimes the complexity is not needed. In any case, the internal libc interfaces must stablize before we can move forward. It would be nice to have something for FreeBSD 5.2. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se