svn commit: trunk/uClibc/libc/inet

Denys Vlasenko vda.linux at googlemail.com
Mon Nov 3 10:33:40 UTC 2008


On Mon, Nov 3, 2008 at 9:37 AM, Bernhard Reutner-Fischer
<rep.dot.nop at gmail.com> wrote:
> On Sun, Nov 02, 2008 at 11:07:46PM +0100, Denys Vlasenko wrote:
>>On Sunday 02 November 2008 11:59, Bernhard Reutner-Fischer wrote:
>>> On Sun, Nov 02, 2008 at 12:42:58AM +0100, Denys Vlasenko wrote:
>>>
>>> >P.S. our resolver is scary. Locking is busted.
>>> >I fear handling of IPv6 DNS replies are busted too.
>>>
>>> The resolver needs a rewrite, agree 100%.
>>
>>I am generally leaning towards fixing existing stuff.
>>Rob is "total rewrite" guy.
>>
>>If you don't object, I'll work on resolver a bit.
>>Will try to fix locking, etc.
>
> Is the resolver which is in svn now somewhat working or is that
> additional patch that is not yet committed a hard requirement?

No, it can wait.

> If it is not required but would only fix some corner-case, then
> i'd prefer to only apply it after the .30 was branched.

What is the ETA on that?

> Regarding the general state the resolver code is in:
> It doesn't work, nor compile for IPv6-only

That's fixable.

res_init() and its attendant _res structure is far worse.
I checked: busybox uses it only in one place (nslookup),
and from the looks of it, uclibc doesn't use it as busybox
expects.

Ever looked into this _res thing? Feels like designed
by monkeys on drugs. You'd think after having it totally
hardwired to IPv4 they (whoever invented the thing) learned
the lesson and its IPv6 extension would be actually AF_xxx
agnostic. Yeah, fat chance... it's not only hardwired for IPv6
(noticed the pattern?), it's not even clear HOW to use it
for IPv6 either... Then there are these [MAXNS] sized arrays
with MAXNS == 3. Wow. That's a lot. I pity anyone who wants/needs
to use four DNS servers. Too many dude! Your 16GB RAM machine
can't take that!

I have a few ideas what to do with _res, none of them
are too nice. Care to brainstorm a little?
Look into uclibc include/resolv.h and busybox's
networking/nslookup.c. We do:

        if (inet_pton(AF_INET, server, &server_in_addr) > 0) {
                _res.nscount = 1;
                _res.nsaddr_list[0].sin_addr = server_in_addr;
        }

which is happily ignored by uclibc. Should we support this?
If yes, how to syncronize schizophrenic _res and our
internal (hopefully much saner) list of DNS servers?
Say, I have one primary DNS server with IPv6 address
and second one with IPv4 address.

Now nslookup executes above code. Questions:
- what had to be in _res.nscount and _res.nsaddr_list[]
  at this point (imagine that nslookup READS these, not writes.
  what should it see there?)
- after these updates, what DNS server(s) shall we use?

> _and_ it feels bigger than needed. So, if you want to beat
> this current impl into shape to work
> - IPv4 only
> - IPv6 only
> - both IPv4 and IPv6
> - plus all 3 above with proper locking
> - all that with at most the size it currently has
> then that'd be fine with me, of course.

Ok, working on this, not committing patches until .30
is created.
--
vda



More information about the uClibc mailing list