On Tue, Jan 21, 2003 at 10:59:11AM +0900, itojun@iijlab.net wrote:
  | >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)


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.

luke.