On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@xxxxxxxxxx> writes:
>
> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@xxxxxxxxxx> 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.
Yes. Same firmware may support different boards that have same pci
controller but on different addresses. Device name may even contain
manufacturer ID, so firmware will be able to find matching driver and
support more board without recompiling.
>
> > 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.
>
Yes, and? That what I wrote above. "ethernet" part is redundant in case
of PCI bus. A little bit of redundancy will not hurt and required by the
spec.
> 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?
Manufacturer ID may be put along with pci. Full FDT contains much more
information about each node though. It may even list compatible HW. Here
we are concerned with device paths only.
>
> >> 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?
I haven't noticed we have alias! What is it used for? I think I can use
it instead.
>
> Do you envisage different device models sharing the same driver_name?
>
Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
> [...]
> >> 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.
>
In cases where this is the case I just use "name".
> > I am looking on existing implementations an copy what they do.
> [...]
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
