From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDHH-0000eu-CW for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:09:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoDHB-00018E-KG for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:09:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDHB-00017x-9g for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:09:01 -0500 Date: Fri, 20 Jan 2012 10:08:54 -0200 From: Luiz Capitulino Message-ID: <20120120100854.1a43ddf0@doriath> In-Reply-To: <4F192635.9010707@redhat.com> References: <1325858501-25741-1-git-send-email-stefanha@linux.vnet.ibm.com> <1325858501-25741-9-git-send-email-stefanha@linux.vnet.ibm.com> <4F18AF21.7010705@redhat.com> <4F192635.9010707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 08/15] qmp: add block_job_cancel command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Marcelo Tosatti , Eric Blake , Stefan Hajnoczi , qemu-devel@nongnu.org On Fri, 20 Jan 2012 09:30:45 +0100 Kevin Wolf wrote: > Am 20.01.2012 01:02, schrieb Eric Blake: > > On 01/06/2012 07:01 AM, Stefan Hajnoczi wrote: > >> Add block_job_cancel, which stops an active block streaming operation. > >> When the operation has been cancelled the new BLOCK_JOB_CANCELLED event > >> is emitted. > >> > >> Signed-off-by: Stefan Hajnoczi > > > >> +++ b/hmp-commands.hx > >> @@ -98,6 +98,20 @@ Set maximum speed for a background block operation. > >> ETEXI > >> > >> { > >> + .name = "block_job_cancel", > >> + .args_type = "device:B", > >> + .params = "device", > >> + .help = "stop an active block streaming operation", > >> + .mhandler.cmd = hmp_block_job_cancel, > >> + }, > >> + > > > > Looking at this from libvirt's perspective, would it be possible to give > > this a different name? Then libvirt would know that if > > block_job_cancel_async exists, we have the official semantics; and if it > > doesn't exist, then we can try block_job_cancel as a fallback to see if > > we have the old blocking semantics. > > > > But by using the same name as the old unofficial blocking command, it's > > difficult to tell if we should expect an event, or whether completion of > > the command means completion of the cancel. > > > > On the other hand, I guess we can rely on completion of the command, > > followed by reading block job status to see if the job is still in > > flight, will tell us whether we need to worry about waiting for an event > > - if the job is complete (whether or not this command was the blocking > > variant), we are done; if the job is ongoing, we have the new semantics > > and can expect an event; and that only leaves the race of calling the > > command, then the job completes, then we query and see it done, then the > > event comes, where we just have to be ready to ignore an unexpected event. > > You're quoting the HMP part, is that intentional? You shouldn't be using > this at all. > > Anyway, are there even any qemu versions out there that implement an > older interface? > > >> +## > >> +# @block_job_cancel: > >> +# > >> +# Stop an active block streaming operation. > >> +# > >> +# This command returns immediately after marking the active block streaming > >> +# operation for cancellation. It is an error to call this command if no > >> +# operation is in progress. > >> +# > >> +# The operation will cancel as soon as possible and then emit the > >> +# BLOCK_JOB_CANCELLED event. Before that happens the job is still visible when > >> +# enumerated using query-block-jobs. > > > > Is there any policy on _ vs - in command names? It seems awkward to > > have block_job_cancel but query-block-jobs. > > block_job_cancel is HMP, whereas query-block-jobs is a QMP command. QMP > uses - consistently. Not sure if HMP is consistent, but it tends to use _. This very series broke QMP's consistency because it was designed when we were following HMP's inconsistencies...