Michael Bushkov wrote: > Hello Terry, Hello back,
[ ... ] > Ok, so if we do a daemon and call all nss_functions from it - will it > help? We'll solve all the problems with statically/dinmically linked > programs and we'll be able to make some caching, by > the way. > > We've done such work. As a start, we have implemented nss_files module, which > worked wit a special NSSD daemon. Libc communicated with them using > sockets. That decision worked quite fast and was very stable. If we > port nss_ldap (by PADL.com) and add some caching procedures, we'll > have almost a lookupd analog. Quite cool! NB: If you are strict NSS, you might be able to use the nss_ldap from FreeBSD without modification. I think this is ideal, so long as you can have multiple concurrent requests (e.g. there is at least a 64bit tag that gets given with the request and returned with the response, which can be a thread ID or other opaque data) on the same connection. This would permit the creation of *_r functions for libc with a fixed overhead which does not increase per thread per request. I think you would need to have someone work on the actual libc code to go with the daemon, as a proof of implementation, but I think it's probably exactly what the doctor ordered! I love that people do real research on things like this! 8-). Is your code under a particular license, and are there some proof of concept *_r routines, or do you need some volunteers to help you work on anything? What would help you move forward on this? Regards, -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
