From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nbyto-0000ts-FD for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:13:16 -0500 Received: from [199.232.76.173] (port=45476 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nbyto-0000ta-0v for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:13:16 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nbytk-0005al-ST for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:13:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53570) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nbytj-0005Zb-1Z for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:13:11 -0500 Date: Mon, 1 Feb 2010 14:12:51 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 2/5] socket: Add a reconnect option. Message-ID: <20100201141251.65a527ae@doriath> In-Reply-To: <4B66F267.3040103@codemonkey.ws> References: <1265031265-14717-1-git-send-email-ian.molton@collabora.co.uk> <1265031265-14717-2-git-send-email-ian.molton@collabora.co.uk> <1265031265-14717-3-git-send-email-ian.molton@collabora.co.uk> <4B66F267.3040103@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Ian Molton , qemu-devel@nongnu.org On Mon, 01 Feb 2010 09:25:27 -0600 Anthony Liguori wrote: > On 02/01/2010 07:34 AM, Ian Molton wrote: > > Add a reconnect option that allows sockets to reconnect (after a > > specified delay) to the specified server. This makes the virtio-rng driver > > useful in production environments where the EGD server may need to be restarted. > > > > Signed-off-by: Ian Molton > > > > I went back and looked at the last series and found my feedback. I had > suggested that instead of automatically reconnecting, a mechanism should > be added for a user to initiate a reconnect. > > Additionally, we should emit events upon disconnect through QMP (now > that we have that functionality). Should we merge all disconnect events or should we keep them separated? I mean, we currently have VNC_DISCONNECT and will likely have SPICE_DISCONNECT. Maybe we could have a SOCKET_DISCONNECT and have a 'source' member, like: { "event": "SOCKET_DISCONNECT", "data": { "source": "vnc" ... } } I can see two drawbacks: 1. We can't do this for connects, which will make this inconsistent 2. Its "data" member is dependent on the source, which makes this event return a set of different info (say vnc auth types vs. auth types) So, I'd keep them separated.