Subject: Re: nsswitch.conf and irs.conf
To: Luke Mewburn <lukem@netbsd.org>
From: None <itojun@iijlab.net>
List: tech-net
Date: 01/21/2003 11:37:11
>  | >Yes, so we need to fix those as well.
>  | >
>  | >Replacing getaddrinfo(3) et al with the IRS versions will make it
>  | >harder for us in support dynamic loading of nsswitch back-ends, 
>  | >and limit us to just using what backends IRS currently implements.
>  | 
>  | 	could you tell me why we can't dynamically-load IRS backends?
>  | 	it looks to me just a matter of updating acc_names[] and accs[] in
>  | 	lib/irs/gen.c, so the same amount [of labor] as dynamically-loadable
>  |	nsswitch backend will make dynamically-loadable IRS backend.
>
>not necessarily.  here's how I see it:
>
>* nsswitch:
>    -	nsdispatch(3) needs to be made thread safe
>    -	nsdispatch(3) needs to support loading dynamic "database"
>    	modules (where a "database" is "files", "dns", "nis", etc)
>    -	gethost* (et al) need to be updated to support bind8 resolver
>    	routines for "dns" lookups (and use existing netbsd code
>	for all other databases)
>    -	single API for end users who want to add extra front-ends
>    	(getfooby*) or database backends (either statically compiled
>	in, or dynamically loaded)
>
>* irs for gethost*, nsswitch for the rest:
>    -	nsdispatch(3) needs to be made thread safe
>    -	nsdispatch(3) needs to support loading dynamic "database"
>    	modules (where a "database" is "files", "dns", "nis", etc)
>    -	irs needs to support nsswitch.conf
>    -	irs needs to support loading dynamic "database" modules
>    -	multiple APIs for end users who want to add extra front-ends
>    	(getfooby*) or database backends (either statically compiled
>	in, or dynamically loaded)

	irs framework supports not just gethost*.  so there's third option -
	irs for all lookups (to name the type of lookups, group, passwd,
	services, protocols, hosts, networks, netgroup).

>using the latter would result in *more* work for end-users wishing to
>add extra front- or back-ends (two APIs instead of one to deal with),
>and more work for us.

	on nsswitch side you didn't count the labor of making non-dns lookups
	(NIS, /etc/hosts) thread safe.  with irs they are already thread safe.

itojun