From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NbzSy-0005Oh-6o for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:49:36 -0500 Received: from [199.232.76.173] (port=53074 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NbzSx-0005O6-DR for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:49:35 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NbzSv-0002Po-Q8 for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:49:35 -0500 Received: from mail-yx0-f189.google.com ([209.85.210.189]:37857) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NbzSv-0002Pe-IB for qemu-devel@nongnu.org; Mon, 01 Feb 2010 11:49:33 -0500 Received: by yxe27 with SMTP id 27so374953yxe.4 for ; Mon, 01 Feb 2010 08:49:32 -0800 (PST) Message-ID: <4B670619.5030601@codemonkey.ws> Date: Mon, 01 Feb 2010 10:49:29 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] socket: Add a reconnect option. 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> <20100201141251.65a527ae@doriath> In-Reply-To: <20100201141251.65a527ae@doriath> 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: Luiz Capitulino Cc: Ian Molton , qemu-devel@nongnu.org On 02/01/2010 10:12 AM, Luiz Capitulino wrote: > 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: > Good question. I'd suggest for now, keep them separate events. We can always merge them into a single event later and deprecate the old events. That will give us a better idea of what the data payload needs to be. Regards, Anthony Liguori