[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInf
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure. |
Date: |
Thu, 04 Nov 2010 15:58:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Gleb Natapov <address@hidden> writes:
> On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> Gleb Natapov <address@hidden> writes:
>>
>> > Add "deriver_name" to DeviceInfo to use in device path building. In
>>
>> Typo "deriver". Same in subject.
>>
> Heh.
>
>> > contrast to "name" "driver_name" should refer to functionality device
>> > provides instead of particular device model like "name" does.
>>
>> Why is that useful in a device path?
>>
> Sometimes it is sometimes it is not. Lets look at path like that:
> /address@hidden/address@hidden/address@hidden
>
> It is important to have pci in the fist path element since it defines
> what kind of bus addressing is used by next element address@hidden
It is for consumers that don't know what's sitting at i0cf8 on the
system bus.
> 4 is
> slot number in case of pci bus. On the other hand ethernet part is not
> important since OS can figure it out by looking in pci config space.
The OS does know what's sitting in slot 4 on the PCI bus.
If the OS number doesn't know what's sitting at i0cf8, why is "pci"
sufficient information? Why don't we have to distinguish between the
different PCI host bridges?
>> I'm afraid "driver_name" is too confusing, because we already use
>> "driver" and "name" for the name of the device model: DeviceInfo member
>> name, and qemu_device_opts option name "driver".
> I use "driver_name" here since I am coding to Open Firmware spec now
> and this element in device path is called driver_name by the spec.
Why is it different from our DeviceInfo member name?
We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
need a third?
Do you envisage different device models sharing the same driver_name?
[...]
>> Do we want a free-for-all ad hoc set of values for driver_name? The
>> values become ABI instantly... Can we adopt some existing set of names
>> for device classes? Else, can we define our own with a bit more
>> control?
>>
> I am open to suggestion. Open firmware describes this field as:
>
> The driver name field is a sequence of between one and 31 letters, digits,
> and punctuation characters from the set “, . _ + - ”. Uppercase and
> lowercase characters are distinct. By convention, this name includes
> the name of the device’s manufacturer and the device’s model name
> separated by a “,”. (See the definition of “name” in annex A.)
> Inclusion of the manufacturer name within driver name is especially
> important for devices intended to plug into standard buses, as this
> minimizes the risk of accidental name collisions. It is somewhat less
> important for devices that are permanently attached to a particular
> system. If the manufacturer name component is omitted (i.e., there is
> no “,” within the driver name), the convention is to assume that
> the manufacturer name is the same as that of the nearest ancestor node
> (parent node, or grandparent node, etc.) that has an explicit manufacturer
> name component.
I suspect that's exactly what DeviceInfo member name is.
> I am looking on existing implementations an copy what they do.
[...]
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Markus Armbruster, 2010/11/04
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Gleb Natapov, 2010/11/04
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.,
Markus Armbruster <=
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Gleb Natapov, 2010/11/04
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Markus Armbruster, 2010/11/05
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Gleb Natapov, 2010/11/05
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Markus Armbruster, 2010/11/05
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Gleb Natapov, 2010/11/05
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Markus Armbruster, 2010/11/06
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Gleb Natapov, 2010/11/06
- Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure., Markus Armbruster, 2010/11/06