qemu-devel
[Top][All Lists]
Advanced

[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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]