Date: Fri, 20 Jun 2003 17:43:06 +0400 From: Michael Bushkov <bushman@rsu.ru> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@freebsd.org Subject: Re[2]: nscd for freebsd Message-ID: <31880874.20030620174306@rsu.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31880874.20030620174306>