qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
Date: Fri, 18 Jun 2010 16:14:18 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Markus Armbruster wrote:
> Alex Williamson <address@hidden> writes:
> 
>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>> Alex Williamson <address@hidden> writes:
>>>
>>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>>> 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.
>>>>> This is where I think you're missing a trick. We don't need to augment 
>>>>> the 
>>>>> name, we just need to allow the bus id to be used instead.
>>>> For the case of a hot remove, I agree.  If the user specifies "pci_del
>>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>>> in that slot, just remove it.  However, I still see some use cases for
>>>> device names in the path.  Take for example:
>>>>
>>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>>
>>>> vs
>>>>
>>>> (B): /pci.0/05.0
>>>>
>>>> (removing both the root bridge driver name and the device driver name)
>>> / is the main system bus.  System bus defines no bus address at the
>>> moment.  Therefore, you have to use the driver name i440FX-pcihost.
>> So is the general rule "If a device's parent bus does not provide an
>> address, print device name"?
> 
> I think the general rule for constructing a *canonical* qdev path should
> be:
> 
> * If it's the main system bus, the path is /.
> 
> * If it's another bus, the path is P/B, where P is the canonical path of
>   the device providing the bus, and B is the bus name.  Unambiguous,
>   since no device ever defines two buses with the same name.
> 
> * If it's a device, the path is P/D, where P is the canonical path of
>   the bus.  If the bus defines bus addresses, then D is @A, where A is
>   the device's bus address.
> 
>   We haven't made up our minds whether the else case exists, or what to
>   do if it does.  The simple "else D is the device model driver's name"
>   works only if the bus can't take multiple device models with the same
>   driver.

...which is already on x86 the case with multiple APICs or HPETs on the
system bus.

> 
> The canonical path is not the only path.  For instance, a qdev ID is a
> valid path, but it's not canonical.  /i440FX-pcihost/pci.0/e1000 is
> another valid, non-canonical path.

Not only canonical paths need to be specified, also alias like the
above. We should limit those alias to a required minimum ("required"
means to me: improves human-friendliness compared to canonical form and
preserves backward compatibility where relevant).

Jan

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



reply via email to

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