[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Nov 2013 11:53:42 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: IPv4 and IPv6 addresses in resolv.conf
On Sat, Nov 30, 2013 at 09:13:32AM +0000, Laurent Bercot wrote:
>
> >OK, so how do we detect if the system "has IPv6"? I don't think it's
> >an easy question to answer, but it's not just a rhetorical question
> >either since we need to know for the AI_ADDRCONFIG flag that's not yet
> >working, so this may very well be the right way to go.
>
> Is there any problem with a build-time test that opens an IPv6 socket ?
Yes. There's no reason to expect that the system musl is compiled on
is the same as the system a program later linked to it is later run
on.
> This is what skalibs does and it's been working so far. Of course, any
> build-time test makes cross-compilation difficult, but this is why we
> have configure options, to manually bypass auto-detection when it cannot
> be relied on.
This introduces gratuitous complexity and breakage and like you said
breaks cross-compiling. (Unwritten) musl policy forbids any
configure-time tests that require running compiled programs; this
policy should be followed by all applications, IMNSHO. :-)
Aside from the gratuitous breakage, the reason not to do
configure-time tests that require running compiled programs is that
you don't need to. The fact that you're able to detect the behavior at
test program run-time during configure means you could also detect it
at actual application run-time. The reason for compile/link tests at
configure time is that they're measuring things that can't be measured
at run-time; this doesn't apply to run-time tests.
> >One other option that's of course the safest is just opening two
> >sockets, one for IPv4 and one for IPv6, if both are needed, but that
> >of course complicates, bloats, and slows down the code and adds
> >failure cases so I'd rather avoid it.
>
> s6-dns opens a different UDP socket, with the appropriate address family,
> every time the client changes servers: so the underlying transport matches
musl couldn't open/close them like this because it does all of the
queries in parallel rather than changing servers in series. We could
use two sockets, one for v4 and one for v6, but this seems like
gratuitous complexity.
> exactly what /etc/resolv.conf specifies. You may call it bloated, but I
> believe it does just the right thing (and I'm not one to go for
> unnecessary features at the expense of simplicity). Speed is not an issue
> here, because we're performing network calls: opening sockets is totally
> negligible compared to waiting for the network anyway.
I agree that speed isn't an issue. However holding two open sockets
and file descriptors when only one is needed may be an issue for
systems under heavy open file/socket load.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
