[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: |
Markus Armbruster |
Subject: |
Re: [PATCH v3 01/11] qapi: Restrict query-uuid command to block code |
Date: |
Thu, 01 Oct 2020 14:24:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> +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?
UuidInfo is also used by query-uuid and info uuid. query-uuid returns
whatever was set with option -uuid. Option's help text calls it
"machine UUID".
>> 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.
GuidInfo is used by query-vm-generation-id and info vm-generation-id.
query-vm-generation-id returns the value of property "guid" of the
vmgenid device.
I don't know why we have both.
>> 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?
I'd expect at least all the modules block.json includes:
block-core.json, common.json, crypto.json, job.json, sockets.json.
>> What about reverting the commit? How bad would that be for user mode?
>>
>
> The problem is not user-mode, is linking tools.
Which modules are linked now?