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
