On Tue, Jun 18, 2013 at 03:24:33PM +0200, Gerd Hoffmann wrote: > Hi, > > >> Something like the attached patch? Which is just the bare minimum I'll > >> need for screendump. Basically a one-off bottom half with some monitor > >> infrastructure (job id, error handling). So it isn't for big jobs, but > >> for small jobs which have to wait for something before they execute > >> (spice-server, guest action, whatever). > > > > I only skimmed over the patch, but you need QMP commands to cancel > > and to query running jobs. > > Sure, can easily go on top, just need to stuff the monitor_jobs into a > list and allow ops on it. Just want to make sure the direction I'm > heading to is fine. > > > Also, please move all this stuff to qmp.c > > and do s/monitor/qmp rename. > > Will do. > > > Lastly, is it possible to have the block job QMP API on top of this > > new QMP job API? > > Don't think so. As mentioned above this does short-running jobs as > bottom half whereas block jobs are running in coroutines ...
Maybe we really should do a proper QMP jobs API. Using a BH makes sense for the screenshot case but is orthogonal to the QMP job API. It may be possible to map block jobs onto the QMP jobs API. Of course the blockjob-specific QMP APIs will remain for compatibility. Here's a quick overview of blockjob commands to give a feel for their scope: drive-mirror <args...> Starts a block job and returns nothing. Note that blockjobs do not have ids because they are bound 1:1 with a block device. This was a design mistake, we should really allow for multiple jobs per block device. query-block-jobs Return info on active block jobs. block-job-cancel Mark a block job as cancelled. It will cancel at the earliest opportunity. QMP Events BLOCK_JOB_COMPLETED and BLOCK_JOB_CANCELLED Async events. QMP Event BLOCK_JOB_ERROR Error reporting with BlockDevOnError error handling policy information (i.e. is the job paused waiting for the administrator to fix storage and then continue it?). Stefan
