[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: nssd (was RFC: Going the LDAP/Kerberos way with NetBSD.)
In article <0A86E637-DAA7-4377-8C83-D3C81EE15A48%3am-software.com@localhost>,
Matt Thomas <matt%3am-software.com@localhost> wrote:
>I'm wondering if this would be a good time to resurrect "nssd" (name
>service system daemon).
>Instead of adding all this libc, maybe this would be a good time to
>move this support for a multi-threaded daemon. This would make libc
>and thereby most processes smaller and move the complexity to a single
>Libc could still retain file methods, or if in single user mode, fork
>a helper program to assist in the lookup. For cruchgen'ed programs that
>need this support, the nssd itself could be crunched into the
My experience with nssd has only been pain. While it is a good idea if
properly implemented, I have not seen a proper implementation of it and
I don't think that it is easy to write one. Issues:
1. It introduces a level of cacheing which can lead to annoying
consistency issues if there is more cacheing happening at the
directory server level. What would be ideal is to teach all
the directory server backends to do uncached calls when they
are contacted by nssd.
2. It introduces an extra context switch for each lookup. This is
why sun invented doors.
Main Index |
Thread Index |