On Tue, Nov 17, 2015 at 03:40:58PM -0700, Eric Blake wrote: > 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.
Yeah that commit message is wrong - i'll remove that bit Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|