[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/15] block: Simplify find_block_job() and make
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 04/15] block: Simplify find_block_job() and make it accept a job ID |
Date: |
Tue, 21 Jun 2016 15:36:24 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 06/21/2016 06:27 AM, Alberto Garcia wrote:
> On Mon 20 Jun 2016 08:53:08 PM CEST, Eric Blake wrote:
>>> +static BlockJob *find_block_job(const char *id, const char *device,
>>> + AioContext **aio_context, Error **errp)
>>
>> Can this signature just be const char *id_or_device, rather than two
>> parameters,...
>
> But what if there's a name clash?
All jobs have an id. And legacy users never set an id, so the id of
legacy jobs will always be generated (and you can tell by the #
character in the name that it was a generated id). Basically, I'm
proposing a hierarchical lookup: If the id matches, then you use it. If
the id doesn't match, then do a device lookup name. New code that knows
to set the id should never pass anything but valid ids, so we only have
to worry about the case of new code trying to check the status of a job
that no longer exists and accidentally getting the status of an
unrelated job that happened to belong to a device with the same name -
but any new code shouldn't be that stupid as to use job ids that match
device ids.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH 11/15] blockjob: Add 'id' parameter to 'block-job-cancel', (continued)
[Qemu-devel] [PATCH 15/15] blockjob: Add 'id' field to 'BlockJobInfo' and all BLOCK_JOB_* events, Alberto Garcia, 2016/06/09
[Qemu-devel] [PATCH 03/15] blockjob: Add block_job_get(), Alberto Garcia, 2016/06/09
[Qemu-devel] [PATCH 10/15] blockjob: Add 'id' parameter to 'block-job-set-speed', Alberto Garcia, 2016/06/09