Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster <armbru@redhat.com>]

Gleb Natapov <gleb@redhat.com> writes:

> On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> 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:
> /pci@i0cf8/ethernet@4/ethernet-phy@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 ethernet@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.
[...]