Two copies of resolver routines in libc ?

[Luigi Rizzo]

On Sat, Nov 08, 2008 at 05:39:52PM +0900, Hajimu UMEMOTO wrote:
> Hi,
> 
> >>>>> On Thu, 6 Nov 2008 20:21:03 +0100
> >>>>> Luigi Rizzo <rizzo at iet.unipi.it> said:
> 
> rizzo> While looking for a workaround (attached, read later), i noticed
> rizzo> that libc has two versions of the resolver routines: one is in
...
> rizzo> If we are lucky, this is just replicated code.
> 
> No, the resolver functions in getaddrinfo.c has some addition of
> functionality.  It was done for solving the query order problem.
...
> When we tried to solve the query order problem, we decided to have a
> modification code of the resolver into getaddrinfo.c.  Because:
> 
>   - Hide the internal functions from outside of libc.
>   - Don't change the resolver as possible to ease further merge from
>     ISC BIND.
> 
> Since we have the symbol versioning facility, we can hide the libc
> internal functions from outside of libc, these days.  So, it may
> better to merge the two.  I attached the proposed patch in this mail.
> Please review it.

hi,
thanks for the answer and the effort for merging back the two copies.
I am looking at your proposed patch but i am not sure i understand it fully,
so i would be grateful if you could explain me a few things (btw i
am attaching a version of your patch constructed with 'diff -ubwp'
and couple of formatting changes to remove whitespace differences;
this should make the actual changes more evident):

1. i apologize for my ignorance, but i suppose there is a binding
   between __res_nsearchN() and res_nsearchN(), and the same
   for all function with and without the two leading __ . Where
   is this binding established, as i don't see anything in the
   diff that you sent.

2. res_*() now become wrappers around the newly introduced res_*N()
   functions. While this approach removes the duplication, it does
   not address the "ease further merge from ISC BIND" case, which
   definitely sounded as a valid concern.

   So i wonder, what is it that prevents you from acting the other
   way around, i.e. build the res_*N() around the existing res_*()
   functions ? This way the original ISC code would really be
   unmodified and perhaps the change would be even more confined.

   Does this constraint apply to all three functions (res_query, res_search,
   res_nquerydomain) or only for a subset of them ?

       From what i can tell, at least in res_nquery()
   the only significant change seems to be the following

        +    if (n > anslen)
        +        hp->rcode = FORMERR;    /* XXX not very informative */

   other than that it seems perfectly fine to implement res_nqueryN()
   as a wrapper around the original res_nquery().

   For the other two functions
   and the other one (trspping TRYAGAIN) seems perfectly suitable to
   be implemented in

2. i don't completely understand what is the additional functionality
   in the resolver functions. You mention a 'query order problem'
   but i don't exactly understand what it is and how the functional
   change is implemented.

thanks
luigi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resolv-ubwp.diff
Type: text/x-diff
Size: 6943 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081108/30c823e9/resolv-ubwp.bin