From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 20 06:43:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D17037B401 for ; Fri, 20 Jun 2003 06:43:19 -0700 (PDT) Received: from smtp.aaanet.ru (smtp.aaanet.ru [80.80.111.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C0A843F3F for ; Fri, 20 Jun 2003 06:43:18 -0700 (PDT) (envelope-from bushman@rsu.ru) Received: from [80.80.109.87] (helo=p75) by smtp.aaanet.ru with esmtp (Exim 4.14) id 19TMAX-000K0K-TT; Fri, 20 Jun 2003 17:43:12 +0400 Date: Fri, 20 Jun 2003 17:43:06 +0400 From: Michael Bushkov X-Mailer: The Bat! (v1.62i) Organization: RSU X-Priority: 3 (Normal) Message-ID: <31880874.20030620174306@rsu.ru> To: Terry Lambert In-Reply-To: <3EF2BF54.9CA3604B@mindspring.com> References: <8713472442.20030619163913@rsu.ru> <87k7bi86ve.fsf@PECTOPAH.shenton.org> <3EF29B78.11DF3FA4@mindspring.com> <165845726.20030620095811@rsu.ru> <3EF2BF54.9CA3604B@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re[2]: nscd for freebsd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Michael Bushkov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 13:43:19 -0000 TL> Quite cool! TL> NB: If you are strict NSS, you might be able to use the TL> nss_ldap from FreeBSD without modification. TL> I think this is ideal, so long as you can have multiple TL> concurrent requests (e.g. there is at least a 64bit tag that TL> gets given with the request and returned with the response, TL> which can be a thread ID or other opaque data) on the same TL> connection. This would permit the creation of *_r functions TL> for libc with a fixed overhead which does not increase per TL> thread per request. TL> I think you would need to have someone work on the actual libc TL> code to go with the daemon, as a proof of implementation, but I TL> think it's probably exactly what the doctor ordered! TL> I love that people do real research on things like this! 8-). TL> Is your code under a particular license, and are there some TL> proof of concept *_r routines, or do you need some volunteers TL> to help you work on anything? What would help you move forward TL> on this? TL> Regards, TL> -- Terry Hello again! Thanks for your letter. I'll tell you more details about our nsswitch implementation. We reimplemented nsdispatch function: int nsdispatch(const char *database, const char *method, const void *arg, size_t asize, void **res, size_t *rsize, int *errp) This function connects to our daemon, it bypasses special headers and all function parameters, packed as a single memory segment to it. Daemon calls needed library (as it is said in nsswitch.conf). And library functions must unpack the data, do all the work and return result to daemon, which sends it back to the libc. So daemon doesnt't know anything about parameters - he has them as a single segment. And we call nsdispatch function to retreive data in every libc procedure, that requires Name Service Switch. Our daemon code is quite ready - it doesnt't do any caching, but it's not a problem, i think. And, as i said before, we have a nss_files module - almost ready. Of course, it's a simplest of nss_modules but it is very good for developing and testing. Helping us with this project will be really great! May be will be able to finish it quite soon. We would also be pleased to hear all the ideas and thoughts. We may restucture it if needed. I can send you the sources, if you're interested. They are not under any licenses at the moment. I think, the main task that we currently have is to adapt nss_ldap module for our project (as you see, it's not strict nss). Michael A. Bushkov Computer Center of Rostov State University mailto:bushman@rsu.ru