Gleb Natapov <[email protected]> writes:
> On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> Gleb Natapov <[email protected]> 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:
> /p...@i0cf8/ether...@4/ethernet-...@0
>
> It is important to have pci in the fist path element since it defines
> what kind of bus addressing is used by next element ether...@4.
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.
[...]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
