From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4310 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: IPv4 and IPv6 addresses in resolv.conf Date: Sat, 30 Nov 2013 11:53:42 -0500 Message-ID: <20131130165342.GQ24286@brightrain.aerifal.cx> References: <761df492-c2ee-41d5-84f8-faef313164bf@email.android.com> <20131129174410.GD24286@brightrain.aerifal.cx> <20131130003704.GL24286@brightrain.aerifal.cx> <20131130031744.GM24286@brightrain.aerifal.cx> <20131130035116.GO24286@brightrain.aerifal.cx> <5299AC3C.8020405@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1385830437 1288 80.91.229.3 (30 Nov 2013 16:53:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 16:53:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4314-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 30 17:54:03 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vmnno-0004bE-4W for gllmg-musl@plane.gmane.org; Sat, 30 Nov 2013 17:53:56 +0100 Original-Received: (qmail 24072 invoked by uid 550); 30 Nov 2013 16:53:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24064 invoked from network); 30 Nov 2013 16:53:55 -0000 Content-Disposition: inline In-Reply-To: <5299AC3C.8020405@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4310 Archived-At: 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