Subject: Re: nsswitch.conf and irs.conf
To: Noriyuki Soda <soda@sra.co.jp>
From: None <itojun@iijlab.net>
List: tech-net
Date: 01/20/2003 09:33:21
>> 	now you are talking about nsswitch.conf and irs.conf, not thread-
>> 	safeness of nsswitch() and irs-related functions.  don't mix the topic
>> 	up.
>I think I don't mix the topic up.
>The nsswitch framework can be thread safe, too.
>Look at the implementation of Solaris and Linux.
>Those are both thread safe.
>The thread safeness is a just man power issue.
>Not only switching to the IRS based implementation also requires some
>developers' man power, but also it may require users' man power,
>because it may make some visible change to our users. So, total wasted
>man power with the IRS may be larger than the nsswitch.

	do we have such manpower to maintain separate resolver library from
	BIND8?  this is my fundamental question.  if we have such manpower,
	then fine, please do.  i don't think we have such manpower, and it
	is a waste of manpower to redo everything ISC did.

>IMHO, making visible change to our users without technical requirement
>is bad thing, that's why I'm asking.

	as i said we can make irs library to read nsswitch.conf, and behave
	the same as nsswitch.conf.  this is just a matter of implementation
	detail in src/lib/irs/gen.c.

>> 	if we really need to provide backward compatibility to nsswitch.conf,
>> 	yes, we have to modify irs library to take care of syntax like
>> 	[notfound=return].  however, i'm not really convinced that it is good
>> 	to provide that level of flexibility to users.  in what kind of cases
>> 	this is useful?  could you provide any usage cases?
>
>Think about the following setting in nsswitch.conf:
>	hosts: files nis [unavail=return] dns
>
>This settings may be critical to make sure that addresses which are
>maintained locally cannot be forged. (Yes, such assumption is somewhat
>legacy, but may be still useful on some conditions.)

	ok.

>BTW, I think the way to implement the thread safeness in the IRS library
>is somewhat lame. gethostbyname(3) should be implemented by a call to
>gethostbyname_r(3), rather than vice versa as the IRS currently
>does. Using a thread local strage may make sesne, if you cannot modify

	which source code are you looking at?  i guess you are looking at
	something wrong.  if you look at BIND8 src/lib/irs/gethostent.c,
		gethostbyname() calls gethostbyname_p()
		gethostbyname_p() calls gethostbyname2_p()
		gethostbyname2_p() does the real thing
	so i see no problem here.

itojun