From owner-freebsd-hackers Wed Aug 4 19: 7:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (Postfix) with ESMTP id 2BBDC14BF6 for ; Wed, 4 Aug 1999 19:07:07 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.12 #1) id 11CCug-000EQS-00; Thu, 5 Aug 1999 09:05:46 +0700 Date: Thu, 5 Aug 1999 09:05:45 +0700 (ALMST) From: Boris Popov To: Oscar Bonilla Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NSS Project update In-Reply-To: <19990804121347.B5080@fisicc-ufm.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 4 Aug 1999, Oscar Bonilla wrote: [skip] > 2. Make the C library nsdispatch aware. The dtab[] array will be > filled dynamicaly from the contents of /etc/nsswitch.conf. > I'm still not sure if this has to be done "whithin" the C library > or if nsdispatch should fill the dtab[] array itself and not relay > on the caller (i.e. drop the dtab[] parameter). It seems to me at > this point that the easiest approach is to have nsdispatch fill the > dtab array itself. dtab[] array *should* be filled in nsdispatch, otherwise how will you keep me from writing an empty get*() function ? [skip] > > Someone mentioned that we should still be able to produce statically linked > binaries for things like /stand and /sbin. I suggest making the nsdispatch > (or get* functions) revert to files if everything else fails (not the > modules themselves, but the loading of the modules). How does this sound? Sounds reasonable. If functions that works with local files compiled statically we also not loose perfomance with plain setup. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message