On 11/17/2015 10:00 AM, Daniel P. Berrange wrote: > The socket_connect method accepts a QAPI SocketAddress object > which it then turns into QemuOpts before calling the > inet_connect_opts/unix_connect_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=off && ipv6=off > would be treated the same as ipv4=on && ipv6=on > > Signed-off-by: Daniel P. Berrange <berra...@redhat.com> > --- > util/qemu-sockets.c | 91 > +++++++++++++++++++++-------------------------------- > 1 file changed, 36 insertions(+), 55 deletions(-) >
> ai.ai_flags = AI_CANONNAME | AI_V4MAPPED | AI_ADDRCONFIG;
> - ai.ai_family = PF_UNSPEC;
> + ai.ai_family = inet_ai_family_from_address(saddr, &err);
> ai.ai_socktype = SOCK_STREAM;
>
>
> - if (qemu_opt_get_bool(opts, "ipv4", 0)) {
> - ai.ai_family = PF_INET;
> - }
> - if (qemu_opt_get_bool(opts, "ipv6", 0)) {
> - ai.ai_family = PF_INET6;
I'm using the notation you used in 2/5, where - is unspecified, f is
explicitly false, and t is explicitly true. qemu_opt_get_bool(, 0)
cannot tell the difference between - and f.
The old code treated 4=- and 6=- as PF_UNSPEC; 4=f and 6=f as PF_UNSPEC,
and 4=t and 6=t as PF_INET6. That doesn't quite jive with the commit
message claiming that 4=off (is that '4=-' or '4=f'?) and 6=off was the
same as 4=on (4=t) and 6=on.
However, I definitely agree with using inet_ai_family_from_address()
rather than the old code. The code looks correct, but I want to make
sure the commit message matches before giving R-b.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
