From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9cP7-0008Sf-6R for qemu-devel@nongnu.org; Wed, 05 May 2010 07:04:37 -0400 Received: from [140.186.70.92] (port=55182 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9cP4-0008Qs-OR for qemu-devel@nongnu.org; Wed, 05 May 2010 07:04:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9cP2-00074T-RZ for qemu-devel@nongnu.org; Wed, 05 May 2010 07:04:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15753) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9cP2-00074D-KR for qemu-devel@nongnu.org; Wed, 05 May 2010 07:04:32 -0400 Message-ID: <4BE150BA.2000801@redhat.com> Date: Wed, 05 May 2010 13:04:26 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Patch to improve handling of server sockets References: <4BE049F5.6050105@codemonkey.ws> <4BE0960E.5000407@redhat.com> <4BE131EC.2030704@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Reinhard Max Cc: qemu-devel@nongnu.org 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