From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nc5Aa-0000Sp-5p for qemu-devel@nongnu.org; Mon, 01 Feb 2010 17:55:00 -0500 Received: from [199.232.76.173] (port=40009 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nc5AZ-0000Sd-Rj for qemu-devel@nongnu.org; Mon, 01 Feb 2010 17:54:59 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nc5AU-00081S-Rk for qemu-devel@nongnu.org; Mon, 01 Feb 2010 17:54:59 -0500 Received: from mail-iw0-f187.google.com ([209.85.223.187]:40897) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nc5AU-00080x-AU for qemu-devel@nongnu.org; Mon, 01 Feb 2010 17:54:54 -0500 Received: by iwn17 with SMTP id 17so2228468iwn.18 for ; Mon, 01 Feb 2010 14:54:53 -0800 (PST) Message-ID: <4B675BBA.2080907@codemonkey.ws> Date: Mon, 01 Feb 2010 16:54:50 -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> <4B675967.1060503@collabora.co.uk> In-Reply-To: <4B675967.1060503@collabora.co.uk> 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: Ian Molton Cc: qemu-devel@nongnu.org, Luiz Capitulino On 02/01/2010 04:44 PM, Ian Molton wrote: > Anthony Liguori wrote: > > >> 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. >> > This sounds useful > > >> Additionally, we should emit events upon disconnect through QMP (now >> that we have that functionality). >> > This also. > > >> The main reason I dislike automatic reconnecting is that there is no >> correct way to handle the period of time while the VM is disconnected. >> > This is fine for egd protocol, the guest will just run low on entropy in > the meantime. Nothing should break. > Right, but you're adding a generic piece of functionality. For instance, what's the result of using reconnect with virtio-console? Is this something that is going to work well? >> Auto reconnecting is implementing a policy to handle the failure within >> QEMU which is not universally the correct choice. This isn't so bad >> except for the fact that you aren't providing the mechanisms for users >> to implement other policies which means they're stuck with this >> particular policy. >> > Perhaps this feature could be added if needed in future? It seems a bit > ambitious to get all this 'right' with no use cases to test against. > I'm all for doing things incrementally but there has to be a big picture that the incremental bit fits into otherwise you end up with a bunch of random features that don't work together well. Honestly, I'd strongly suggest splitting the reconnect logic out of the series when resubmitting. I think it's just too hacky with too weak of a justification. If you really want this functionality, we can discuss the right approach for doing it but it's gotta be done in a way that's not introducing a one-off case just for the random number generator. Regards, Anthony Liguori > -Ian >