[ On Saturday, September 13, 2003 at 10:18:59 (-0700), Jason Thorpe wrote: ]
> Subject: Re: nsswitch vs ISC IRS
>
> The changes to make nsswitch thread-safe have already been made by a 
> 3rd party, and will be integrated into NetBSD in the near future.

Ah, this is good news (and news to me! :-) 

> irs, while it does technically exist, requires a significant amount of 
> effort even to integrate into the NetBSD system, much more effort than 
> is required to apply the thread-safety fixes to nsswitch.

Having read the code for both I can very much appreciate that.

I'm not entirely happy with the internals of nsswitch, and though in
some ways IRS looks to have a cleaner start and a more elegant
implementation I'm not in a position to evaluate all of the related
issues.  It would help I suppose if the wayt the getpw*() routines use
nsdispatch() were documented.  The nsdispatch(3) manual page itself is
all fine and good, but none of the magic of cb_data is documented for
any of the primary users of nsdispatch() such as getpw*() or gethost*(),
not even with internal comments so far as I can find.  Hopefully some
better documentation will come along with the new thread-safe version.

>  Even then, 
> irs will not provide all of the functionality that our current nsswitch 
> provides

If I'm thinking of what you're thinking of then that's true enough
(though I'm not sure it's important enough functionality to worry about
keeping, but that's a separate issue).

The issue perhaps then becomes deciding which of IRS v.s. resolver
hacking is more effort.

I would very much like to see at least the BIND-8 resolver code imported
to NetBSD A.S.A.P., and I can very much see how this would be on hell
of a lot easier to do if NetBSD simply used IRS across the board.

I know it doesn't make any sense to import IRS and to front it with
nsswitch -- that's a one-way-street to confusion for everyone for sure.

However porting BIND-8 to NetBSD w/nsswitch seems like it will be a lot
of work -- work that will not be easy to automate for any new releases
of the BIND-8 resolver code either (though perhaps we're nearing the end
of any major shakeups in their internals, so automation via patch may be
sufficient).

Alternately moving NetBSD to the BIND-9 lwres would be fun!  ;-)

> and that is even before nsswitch gets support for dynamic 
> loading of modules (changes that implement this are also available from 
> a 3rd party)
> 
>  irs would require a major overhaul to support dynamic 
> loading of modules.

I'm not so sure about that, but I'm not one who would go about trying to
do such things either.  :-)

> Furthermore, nsswitch is far more common in the Unix world than irs, 
> and so nsswitch buys us a compatiblity-with-other-systems checkbox that 
> irs does not.  (What OSs even ship with irs these days?  BSD/OS?  I 
> can't think of any other OS that does, and BSD/OS is about to go the 
> way of the dodo.)

I'm not sure who needs that kind of compatability.

You must be talking about user-level compatability because although I've
not seen Sun's internals, I can't imagine that they look even remotely
like NetBSD's given what I've seen from the outside and what I've read
in texts describing Sun's implementation.

NetBSD's nsswitch is already incompatible enough with its roots at the
user level to cause at least some minor confusion for folks I know who
are experts with _using_ the likes of the Solaris implementation.

I.e. I just don't think compatability of some sort is a useful enough
argument to bother with.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>