All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Reinhard Max <max@suse.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Patch to improve handling of server sockets
Date: Wed, 05 May 2010 13:04:26 +0200	[thread overview]
Message-ID: <4BE150BA.2000801@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1005051211250.3715@nitsch.suse.de>

   Hi,

>> 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()?

See docs in QMP/*, the changes in monitor.c and q${type}.[ch]

qemu_opt_set() in inet_listen_opts() is only slightly related.  It is 
used to report back the address we've actually bound to.  Used by 'info 
chardev' and I think vnc too.  Yes, that has to be changed somehow ...

>> 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.

I don't know how it 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.

It is probably best to bring this up on the libvirt list, this is the
most important user of those interfaces and I think other virtual machine
management folks are reading there too.

I personally don't care too much which way we pick.

> 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.

Good point.

cheers,
   Gerd

  reply	other threads:[~2010-05-05 11:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-04 13:49 [Qemu-devel] Patch to improve handling of server sockets Reinhard Max
2010-05-04 16:23 ` Anthony Liguori
2010-05-04 20:44   ` Reinhard Max
2010-05-04 21:47     ` Anthony Liguori
2010-05-04 21:47   ` Gerd Hoffmann
2010-05-04 21:50     ` Anthony Liguori
2010-05-04 23:28       ` Reinhard Max
2010-05-05 15:01       ` Daniel P. Berrange
2010-05-04 23:42     ` Reinhard Max
2010-05-05  8:53       ` Gerd Hoffmann
2010-05-05 10:42         ` Reinhard Max
2010-05-05 11:04           ` Gerd Hoffmann [this message]
2010-05-05 17:14         ` Daniel P. Berrange
2010-05-05  8:29 ` Daniel P. Berrange
2010-05-05 17:44   ` Reinhard Max

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BE150BA.2000801@redhat.com \
    --to=kraxel@redhat.com \
    --cc=max@suse.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.