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

[Gleb Natapov]

On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
> Gleb Natapov <address@hidden> writes:
> 
> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
> >> 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.
> > 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.
> 
> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
> Why don't we have to identify the particular host bridge, such as
> "i440FX-pcihost"?
> 
As I said below manufacturer ID may be part of device name. It should be
separated by comma though. Something like "i440FX,pci". But for x86 qemu
emulation this is not needed since all chipsets implement essentially
the same pci controller. Other platforms qemu emulates may use more
elaborate names. Other platforms may want to get full FDT tree from
qemu anyway.

> >> >                                                                 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.
Here I said it already :)

> >
> >> 
> >> >> 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.
> 
> But they're different devices!  Isn't Open Firmware's "driver name"
> meant to identify a device type unambigously?
> 
Not necessary as far as I see from examples. Full FDT contains more
info. In this case all of those different devices present exactly same
HW interface, so from FW point of view they are the same. To make FW
life more easy it is better to have one name for all of them.

> Consider the case of an ISA soundcard providing an IDE channel.  Want to
> call it "ata", too?
If it is exactly like interface provided by devices above why FW cares
that this is soundcard?

--
                        Gleb.