qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 08/15] qmp: add block_job_cancel command


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 08/15] qmp: add block_job_cancel command
Date: Tue, 10 Apr 2012 12:06:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 01/20/2012 12:55 PM, Eric Blake wrote:

Revisiting this thread, as I'd really like to have a solution in place
before qemu 1.1 is released.

>>> 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.
>>>

> 
> The older interface was backported into RHEL 6.2 qemu, so libvirt has to
> maintain the distinction (although it can equally be argued that the
> distinction only exists in the RHEL build, and therefore, only the RHEL
> build of libvirt has to deal with the issues of an early backport of a
> qemu feature).
> 
>>> 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 _.
> 
> OK, on RHEL 6.2, 'help' on HMP includes help for block_job_cancel, and
> '{"execute":"query-commands"}' on QMP includes
> {"name":"block_job_cancel"}, with underscores in both locations.  So if
> your new QMP command is block-job-cancel, you've met the goal of having
> a different spelling from the RHEL backport of the earlier semantics.
> And if you stuck with underscores, then it's RHEL's problem to solve :)

Are we settled enough on the 'drive-mirror' command to commit to that in
the qapi in time for qemu 1.1, even if we don't implement it until qemu
1.2?  That would be a sufficient witness of another block job command
that therefore implies job cancellation is asynchronous.  If we don't
commit to 'drive-mirror' in time, then what else can libvirt use to
distinguish between RHEL 6.2 synchronous 'block_job_cancel' and the
asynchronous command introduced by this series?

Is it too late to rename the QMP command to 'block-job-cancel'?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]