Date: Thu, 17 Apr 2003 20:09:35 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: new NSS Message-ID: <20030418010935.GD4001@madman.celabo.org> In-Reply-To: <200304172044.h3HKi52w032010@khavrinen.lcs.mit.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <nectar@celabo.org> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418010935.GD4001>