From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz4uR-0003dt-BY for qemu-devel@nongnu.org; Wed, 18 Nov 2015 10:44:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz4uM-0000wf-BW for qemu-devel@nongnu.org; Wed, 18 Nov 2015 10:44:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz4uM-0000wb-3X for qemu-devel@nongnu.org; Wed, 18 Nov 2015 10:44:30 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id C8A18461C8 for ; Wed, 18 Nov 2015 15:44:29 +0000 (UTC) References: <1447779624-21625-1-git-send-email-berrange@redhat.com> <1447779624-21625-3-git-send-email-berrange@redhat.com> <564BA88C.1010403@redhat.com> <20151118100821.GB27591@redhat.com> From: Eric Blake Message-ID: <564C9CDC.3040604@redhat.com> Date: Wed, 18 Nov 2015 08:44:28 -0700 MIME-Version: 1.0 In-Reply-To: <20151118100821.GB27591@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AIrfG4INJM8CwcnHUlIDeGejtWWaKhHbr" Subject: Re: [Qemu-devel] [PATCH v2 2/5] sockets: remove use of QemuOpts from socket_listen List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , qemu-devel@nongnu.org, Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AIrfG4INJM8CwcnHUlIDeGejtWWaKhHbr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/18/2015 03:08 AM, Daniel P. Berrange wrote: > On Tue, Nov 17, 2015 at 03:22:04PM -0700, Eric Blake wrote: >> On 11/17/2015 10:00 AM, Daniel P. Berrange wrote: >>> The socket_listen method accepts a QAPI SocketAddress object >>> which it then turns into QemuOpts before calling the >>> inet_listen_opts/unix_listen_opts helper methods. By >>> converting the latter to use QAPI SocketAddress directly, >>> the QemuOpts conversion step can be eliminated >>> >>> This also fixes the problem where ipv4=3Doff && ipv6=3Doff >>> would be treated the same as ipv4=3Don && ipv6=3Don >>> >>> + * ipv4 ipv6 family >>> + * - - PF_UNSPEC This says I have no preference, so pick the one that works. >>> + * - f PF_INET >>> + * - t PF_INET6 >>> + * f - PF_INET6 >>> + * f f >>> + * f t PF_INET6 >>> + * t - PF_INET >>> + * t f PF_INET >> >> These I understand, Generally to mean "I specifically requested this" or "I specifically don't want that", where there is no collision. >> >>> + * t t PF_INET6 >> >> but why is this one PF_INET6 instead of PF_UNSPEC? >=20 > If you use PF_UNSPEC, then the addresses we listen on will be automatic= ally > deteremined by results of the DNS lookup. ie if DNS only returns an IPv= 4 > address, it won't listen on IPv6. When the user has said ipv6=3Don, th= en > they expect to get an error if it was not possible to listen on IPv6. S= o > we must use PF_INET6 here to ensure that error, otherwise ipv6=3Don & i= pv4=3Don > would be no different from ipv6=3D- & ipv4=3D-. But if I'm specifically requesting that both families be used, either that should be an error (we can't honor two families at once) or it should be allowed (use the family that makes sense), not a synonym for ipv6-only. >>> @@ -219,13 +251,15 @@ listen: >>> freeaddrinfo(res); >>> return -1; >>> } >>> - qemu_opt_set(opts, "host", uaddr, &error_abort); >>> - qemu_opt_set_number(opts, "port", inet_getport(e) - port_offset,= >>> - &error_abort); >>> - qemu_opt_set_bool(opts, "ipv6", e->ai_family =3D=3D PF_INET6, >>> - &error_abort); >>> - qemu_opt_set_bool(opts, "ipv4", e->ai_family !=3D PF_INET6, >>> - &error_abort); >>> + if (update_addr) { >>> + g_free(saddr->host); >>> + saddr->host =3D g_strdup(uaddr); >>> + g_free(saddr->port); >>> + saddr->port =3D g_strdup_printf("%d", >>> + inet_getport(e) - port_offset)= ; >>> + saddr->has_ipv6 =3D saddr->ipv6 =3D e->ai_family =3D=3D PF_I= NET6; >>> + saddr->has_ipv4 =3D saddr->ipv4 =3D e->ai_family !=3D PF_INE= T6; >> >> Should we handle PF_UNSPEC specifically, maybe by having the has_ipv6 >> assignment based on e->ai_family !=3D PF_INET? >=20 > The returne e->ai_family from getaddrinfo will never have a value > of PF_UNSPEC - that's an input only value. So we're OK to assume > we'll have PF_INET6 and PF_INET only. Well at least until someone > invents IPv7 but I'll let my great grandchildren deal with that > problem ;-) Okay, but maybe worth a comment somewhere. Or put another way, on input, we can request one or both families, on output, we want to guarantee which family was selected. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --AIrfG4INJM8CwcnHUlIDeGejtWWaKhHbr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWTJzcAAoJEKeha0olJ0NqHYoH/RiFLi4xF47OUzTuzLVBVq7u v0Prf9Tg4YxjpbWVi7ZfzLurkiYFNKxe7N0X42Xnvx6g1wz0A0CyY2bZcg4ILFhG BkE4axQjT4WjtZsOtZxshka7aRY60UqAVmIyxbJVTrrVce+DaT0AiDqGZVXJWmNG C8aWx5tRc0lHcEtU4T5pLHUW0bSApBwuOXYHniskB/P5uEVldAB1srP/CQQ/AWcm 2qs1Rmp+s20nzpDthZJ7mv8Kr/m+cTPQSsua1RNhAEJ99Ldw7M7JBZlL2TrlRKPK 0xQAwXJogrCF1kNizXMgoSRoMH5JbDclfrqCvbi8m9CjDjoLNcGA0z4Dup0/9s4= =C+Q8 -----END PGP SIGNATURE----- --AIrfG4INJM8CwcnHUlIDeGejtWWaKhHbr--