On 12/21/2015 07:31 AM, Kevin Wolf wrote:
> Am 17.12.2015 um 01:50 hat John Snow geschrieben:
>> In working through a prototype to enable multiple block jobs. A few
>> problem spots in our API compatibility become apparent.
>>
>> In a nutshell, old Blockjobs rely on the "device" to identify the j
Am 17.12.2015 um 01:50 hat John Snow geschrieben:
> In working through a prototype to enable multiple block jobs. A few
> problem spots in our API compatibility become apparent.
>
> In a nutshell, old Blockjobs rely on the "device" to identify the job,
> which implies:
>
> 1) A job is always atta
On 12/18/2015 02:24 PM, John Snow wrote:
>> To be subclassable, we need a flat union, and the discriminator must be
>> non-optional within that union. Either 'options' is that flat union
>> (and we have a layer of {} nesting in QMP}, or we directly make the
>> 'data' of job-cancel be the flat uni
On 12/18/2015 01:07 PM, Eric Blake wrote:
> On 12/16/2015 05:50 PM, John Snow wrote:
>> In working through a prototype to enable multiple block jobs. A few
>> problem spots in our API compatibility become apparent.
>>
>
>> qmp_query_block_jobs
>>
>
>> Let's consider using a new comman
On 12/16/2015 05:50 PM, John Snow wrote:
> In working through a prototype to enable multiple block jobs. A few
> problem spots in our API compatibility become apparent.
>
> qmp_query_block_jobs
>
> Let's consider using a new command. I'm not sure if this is strictly
> possible with cu
In working through a prototype to enable multiple block jobs. A few
problem spots in our API compatibility become apparent.
In a nutshell, old Blockjobs rely on the "device" to identify the job,
which implies:
1) A job is always attached to a device / the root node of a device
2) There can only b
