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 <vsement...@virtuozzo.com> writes: >>> >>>> Move to way of device selecting, however fall back to device name if >>>> path is not found. >>>> >>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >>>> --- >>>> 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, Vladimir