Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()

[Jan Kiszka]

Markus Armbruster wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> Markus Armbruster wrote:
>>> Jan Kiszka <address@hidden> writes:
>>>
>>>> Markus Armbruster wrote:
>>>>> Paul Brook <address@hidden> writes:
>>>>>
>>>>>> Alex Williamson <address@hidden> writes:
>>>>>>
>>>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>>>> parent bus and device"?  They make the result ver much *not* a "dev
>>>>>>>> path" in the qdev sense...
>>>>>>> In order to try to get a unique string.  Without looking into device
>>>>>>> properties, two e1000s would both be:
>>>>>>>
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>>
>>>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>>>> to instance ids again.  The goal here is that anything that makes use of
>>>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>>>> You already got the information you need, you just put it in the wrong 
>>>>>> place. 
>>>>>> The canonical ID for the device could be its bus address. In practice 
>>>>>> we'd 
>>>>>> probably want to allow the user to specify it by name, provided these 
>>>>>> are 
>>>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci 
>>>>>> would 
>>>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so 
>>>>>> we 
>>>>>> can use an initial prefix to disambiguate a name/label from a bus 
>>>>>> address.
>>>>>>
>>>>>> For busses that don't have a consistent addressing scheme then some sort 
>>>>>> of 
>>>>>> instance ID is unavoidable. I guess it may be possible to invent 
>>>>>> something 
>>>>>> based on other device properties (e.g. address of the first IO 
>>>>>> port/memory 
>>>>>> region).
>>>>> When that's inconvenient or impossible, we can still punt to user: make
>>>>> device ID mandatory.
>>>> No option due to auto-created devices. And auto-generating IDs would
>>>> just create usability issues.
>>> Auto-generated IDs would become part of the ABI.  Really so bad that
>>> it's "no option"?  Mind, device ID becomes mandatory *only* for devices
>>> that don't have a useful bus address.  We could even waive the ID
>>> requirement for the first device of a kind, i.e. require ID if and only
>>> if it's needed to disambiguate.
>> IDs are there to find devices the user (or a higher level tool) passed
>> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
>> a well-organized hierarchy. That allows to explore and address a qtree
>> element at the same time.
>>
>>>>> We obviously need a way to unambigously name a device.  It's okay to
>>>>> have multiple names for the same device.
>>>>>
>>>>> If the device has a device ID, that's an unambigous name.
>>>>>
>>>>> qdev paths may be ambigous when path components are resolved to driver
>>>>> names instead of IDs.
>>>>>
>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>> immediate parent bus and device" to the path component.  For PCI, these
>>>>> are dev.fn.  Likewise for any other bus where devices have unambigous
>>>>> bus address.  The driver name carries no information!
>>>> >From user POV, driver names are very handly to address a device
>>>> intuitively - except for the case you have tones of devices on the same
>>>> bus that are handled by the same driver. For that case we need to
>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>> address where available, otherwise based on instance numbers.
>>> I'm not arguing against the use of driver names at all.
>>>
>>>>> For other buses, we need to make something up.
>>>>>
>>>>> Note that addressing by bus address rather than name is generally
>>>>> useful, not just in the context of savevm.  For instance, I'd appreciate
>>>>> being able to say something like "device_del pci.0/04.0".
>>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>>> the bus first before you can identify which device you want to remove.
>>> It's not either/or.  Addressing by ID continues to work.  Addressing by
>>> bus/driver-name continues to work.  We merely add addressing by
>>> bus/@bus-address.
>> The format I will propose is "global-ID|/absolute/path", no more
>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>> bus-local name of a device).
> 
> Doesn't this break existing usage?

Please name one. It could only be weird corner cases like "device_add
driver,bus=bus1/ID/bus2" or "bus=ID/bus". But given that we always
allowed to address "bus2" directly (and this is something I cannot and
will not change), does this really matter? Maybe allowing paths to start
with an ID is something worth considering, will think about this again.

> 
> We have a rule to resolve any ambiguity added by ID: it always takes
> precedence over driver name.  What path/ID does add is shadowing: it can
> make a device inaccessible by driver name.  Not much of a difference to
> adding a second device with the same driver name.

ID was introduces as a _global_ address, there is simply no point using
it _inside_ qtree paths, it will just cause troubles and confusions.
Rather, we need to resolve the ambiguity of bus-local names - what this
thread is about.

> 
>>>>> An easy way to get that is to reserve part of the name space for bus
>>>>> addresses.  If the path component starts with a letter, it's an ID or
>>>>> driver name.  If it starts with say '@', it's a bus address in
>>>>> bus-specific syntax.  The bus provides a method to look it up.
>>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>>> set for buses that implement some to-be-defined device addressing
>>>> service, the latter is the default on buses where that service is not
>>>> available.
>>> I object to <driver>@<bus-address>, because the <driver> part carries no
>>> information.
>> I does for a human being as bus addresses tend to be unreadable and can
>> easily be confused, hence the additional, sometimes redundant driver name.
> 
> I *strenuously* object to making the driver name mandatory with
> bus-address addressing.
> 
> If you think the human user needs to be protected from mistakes by
> making him supply redundant information, then "device_del pci.0/04.0
> e1000" is much better way than complicating device paths for human and
> machine users alike, not to mention uses internal to QEMU.

The only think that may speak against expressive device names might be
the overall path length. Not sure if we can already reach critical
limits for any involved subsystem, though. Anything else can and should
easily be encapsulated for qdev users in a single service providing the
unique device name for a given device - independent of the final format.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux