Two copies of resolver routines in libc ?
rizzo at iet.unipi.it
Sat Nov 8 07:05:47 PST 2008
On Sat, Nov 08, 2008 at 05:39:52PM +0900, Hajimu UMEMOTO wrote:
> >>>>> 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6943 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081108/30c823e9/resolv-ubwp.bin
More information about the freebsd-net