Re: [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitrary node

[Alberto Garcia]

On Fri 06 May 2016 07:54:36 PM CEST, John Snow wrote:
>>>> @@ -3694,18 +3696,18 @@ static BlockJob *find_block_job(const char 
>>>> *device, AioContext **aio_context,
>>>>  
>>>>      *aio_context = NULL;
>>>>  
>>>> -    blk = blk_by_name(device);
>>>> -    if (!blk) {
>>>> +    bs = bdrv_lookup_bs(device_or_node, device_or_node, errp);
>>>
>>> Specifically, this one is bad. It allows two different ways to specify
>>> the same job.
>> 
>> I think we can simply iterate over all block jobs (now that we have a
>> function to do that) and return the one with the matching ID.
>
> I think it's time to add a proper ID field to Block Jobs. Currently,
> we just use the node-name as the ID, but as you are aware this is a
> poor mechanism for fetching the job.
>
> I'd really like to avoid continue using any kind of node-name or
> block/device-name for job IDs, and instead start using either a
> user-provided value or a QEMU auto-generated one.
>
> Then, for legacy support, we'd have an "id" field (that's the new
> proper globally unique ID) and an old legacy "node" field or similar.
>
> Then, for events/etc we can report two things back:
>
> (1) Legacy: the name of the node we were created under. This is like
> it works currently, and it should keep libvirt happy.
> (2) New: the proper, real ID that all management utilities should
> begin using in the future.

Do we really need to have those two? Isn't it possible to do it with a
single ID?:

- New commands that create block jobs have a parameter to specify the
  job ID (if we don't choose to generate them automatically).

- Existing commands (block-stream, block-commit, etc) can also have a
  new (optional) parameter to set the job ID. If omitted, they use the
  device name (exactly as they do now).

Berto