From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23pT-0004we-IT for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:53:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S23pN-000618-I4 for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:53:39 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:54444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S23pN-00060x-BC for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:53:33 -0500 Received: by pbbro12 with SMTP id ro12so6667121pbb.4 for ; Mon, 27 Feb 2012 08:53:32 -0800 (PST) Message-ID: <4F4BB507.7090907@codemonkey.ws> Date: Mon, 27 Feb 2012 10:53:27 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1a226638-a248-4fbf-9269-e39231407a13@zmail16.collab.prod.int.phx2.redhat.com> In-Reply-To: <1a226638-a248-4fbf-9269-e39231407a13@zmail16.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Federico Simoncelli Cc: kwolf@redhat.com, Jeff Cody , mtosatti@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Luiz Capitulino >> On 02/27/2012 10:33 AM, Federico Simoncelli wrote: >>> I'm all for the modularity of the commands (I suggested it since >>> the beginning), >>> but all this infrastructure goes way beyond what I'd need for oVirt >>> now. >>> >>> When I submitted my patches we knew that my work wasn't the >>> definitive solution >>> (eg: the future implementation of -blockdev). So I'd suggest to try >>> and settle >>> with something that is good enough and that is not preventing a >>> future improvement. >>> >>> What about having a (temporary) flag in drive-mirror to accept also >>> a new-image-file >>> until we will have the optimal solution? >> >> Unless there are extenuating circumstances (like the absence of core >> infrastructure in QEMU), then we should not add commands that we know >> are not >> the right command. > > So are you in favor or against my suggestion? Against. I think we have everything we need. > It looks like this is exactly > the case where the core infrastructure (transactions) is missing. Batch requests are incredibly easy to add. I'm stuck in meetings for the next couple days but I'm sure Luiz throw it together in no time at all. Regards, Anthony Liguori >