Hi,
On Wed, 5 May 2010 at 10:53, Gerd Hoffmann wrote:
Noticed that it probably should get a few helper functions to handle
FdLists to avoid the quite simliar open-coded loop-over-all-fds
loops all over the place.
indeed, thanks for the hint. I now have functions to create a new list
element from an fd number and to destroy a list. Not sure if straight
loops over existing lists can be further optimized, though.
You'll run into qmp for sure when forward-porting the patches to the
latest qemu bits. It is the machine-readable version of the monitor
protocol (in qemu 0.12+).
I guess that's the qemu_opt_set() calls at the end of
inet_listen_opts()?
First I think qemu should be self-consistent here, i.e. either
report the (single) name or the list of addressed everythere.
Yes, this mixture wasn't meant to be final, but it helped me getting
the initial patch done with a minimal set of changes.
Second we have to care about the current users (especially libvirt).
Wouldn't the users of that bit of information run it through
getaddrinfo() anyways when trying to connect? So to them it shouldn't
matter whether the name or an ASCII representation of the address is
used.
Today qemu usually reports the address I think. Thus I tend to
stick to addresses to keep them happy.
But wouldn't going from single address to multiple addresses be a
bigger change for the users (and likely break them all) while going
from address to name would only break those that were not using
getaddrinfo() to translate the address into its binary representation.
OTOH, going for multiple addresses would also allow starting qemu with
more than a single -vnc option, which doesn't seem to be possible
right now, and wich might come handy in situations when the set of
addresses a qemu instance should be listening on is not available as a
single DNS name.
cu
Reinhard
