[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 1/2] qapi: move to QOM path for x-block-laten

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v3 1/2] qapi: move to QOM path for x-block-latency-histogram-set
Date: Mon, 11 Feb 2019 18:33:31 +0000

11.02.2019 20:52, Kevin Wolf wrote:
> Am 11.02.2019 um 18:39 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 08.01.2019 16:20, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy <address@hidden> writes:
>>>> Move to way of device selecting, however fall back to device name if
>>>> path is not found.
>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>>>> ---
>>>>    qapi/block-core.json |  4 ++--
>>>>    blockdev.c           | 22 +++++++++++++++-------
>>>>    2 files changed, 17 insertions(+), 9 deletions(-)
>>>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>>>> index 762000f31f..bb70c51a57 100644
>>>> --- a/qapi/block-core.json
>>>> +++ b/qapi/block-core.json
>>>> @@ -489,7 +489,7 @@
>>>>    # If only @device parameter is specified, remove all present latency 
>>>> histograms
>>>>    # for the device. Otherwise, add/reset some of (or all) latency 
>>>> histograms.
>>>>    #
>>>> -# @device: device name to set latency histogram for.
>>>> +# @id: The QOM path or name of the guest device.
>>>>    #
>>>>    # @boundaries: list of interval boundary values (see description in
>>>>    #              BlockLatencyHistogramInfo definition). If specified, all
>>> Is such overloaded semantics what we want in new interfaces?
>>> Hmm, looks like there's ample precedence for it.  Escaped my grep at
>>> first because its commonly documented as "The name or QOM path of the
>>> guest device".  Suggest to stick to that for consistency.
>> Interesting, that in cases you mean, documentation seems wrong:
>> it goes through qmp_get_blk, which works like @id may be only QOM path, not 
>> name,
>> so for the it should be @id: The QOM path.
> It's really a QOM path relative to /machine/peripheral (see
> find_device_state()), which is where named devices live, accessible
> through their id. So relative paths are both QOM paths and names of
> guest devices. (Relative paths aren't a QOM concept, though, which
> provides only absolute and partial paths. The relative paths have a
> one-off implementation here.)
> So in the end, I think the description is actually correct, just with a
> higher level perspective, ignoring all the low-level details.

Hmm I thought, that name is an argument of blk_by_name() and path is an
argument of blk_by_qdev_id.. But you say that argument of blk_by_qdev_id
may be considered as "name" too, at least for user. If so, that is ok..

Consider more context:

   # @device: Block device name (deprecated, use @id instead)
   # @id:     The name or QOM path of the guest device (since: 2.8)

so, "name" in first line and "name" in second are different kinds of name?

Best regards,

reply via email to

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