[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 01/11] qapi: Restrict query-uuid command to block code
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v3 01/11] qapi: Restrict query-uuid command to block code |
Date: |
Thu, 1 Oct 2020 12:22:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
+Igor
On 10/1/20 7:04 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>
>> In commit f68c01470b we restricted the query-uuid command to
>> machine code, but it is incorrect, as it is also used by the
>> tools. Therefore move this command again, but to block.json,
>> which is shared by machine code and tools.
>>
>> Fixes: f68c01470b ("qapi: Restrict query-uuid command to machine code")
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> UUIDs are not really a block-specific thing.
This is the discussion we had in v1 with Igor...
UuidInfo is a iSCSI-specific "thing", the original commit
is f9dadc9855 ("iSCSI: add configuration variables for iSCSI")
then Paolo introduced 'UuidInfo' in commit 5accc8408f
("scsi: prefer UUID to VM name for the initiator name") but
is misnamed?
>
> QMP query-uuid and HMP info uuid are about the VM, like query-name.
> That's why they used to be next to query-name in misc.json.
This is GuidInfo, not UuidInfo...
GuidInfo is correctly in machine.json.
>
> There's one additional use in block/iscsi.c's get_initiator_name(). I
> figure that's what pulls it into tools via qemu-img.
Yes.
>
> Which other QAPI modules are shared by all the executables that use it?
None?
>
> What about reverting the commit? How bad would that be for user mode?
>
The problem is not user-mode, is linking tools.