What warrants this being dynamic rather than static?

getpwent() gets a request for a password entry.
getpwent() calls the routine that gets the "passwd" line
from nsswitch.conf.
Oh!  It says "file  ldap"!

It calls getpwent_file() with argument.  Sadly, that fails.
So it calls getpwent_ldap().  That works!  Joy!

No dynamic loads, perhaps a shared library, but that's ok.

I just don't want the two blurred together.
Many ways of getting name service info  do not depend on
dynamicly loaded modules (which may be desired for other reasons).

I find dynamic useful when I don't have, hmmm, THE SOURCES?

Quoting Adam Lebsack (adam@lebsack.com):
> Hey guys...
> 
> I know there was a rather heated topic about this a while back, but it 
> seems to have ended with no useful conclusions.
> 
> This concerns the state of dynamically loading nss_* modules.  I have 
> been thinking about this a great deal lately, and it is an huge feature 
> I'd like to see in NetBSD 2.0.  I am willing to try to code this, so 
> I'll detail my plan right here.
> 
> I believe we should use some sort of caching daemon, much like linux's 
> nscd.  However, the failure of the caching daemon would be a problem, 
> so I propose that nss modules should be compatible with both the 
> dynamic libc and the proposed caching daemon.  libc checks for the 
> caching daemon and if it isn't running (which may be the choice of the 
> user), it loads the nsswitch.conf and the proper modules into itself.
> 
> Is someone already working on this?  I know FreeBSD recently got 
> dynamic nss modules.  Anyone know if it works well?  Any feedback 
> before I begin would be greatly appeciated.