[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: |
Kevin Wolf |
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:52:47 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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.
Kevin