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

[Markus Armbruster]

Gleb Natapov <address@hidden> writes:

> 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".

I'd expect "intel,i440FX".

Note that comma makes for extremely user-hostile -device usage.  Right
now, it doesn't work at all.

>                                                         But for x86 qemu
> emulation this is not needed since all chipsets implement essentially
> the same pci controller.

Will it stay that way?  What about Isaku's q35 work?

>                          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.

Okay.  It's a name for a sufficiently compatible set of devices, where
"sufficient compatibility" is defined from the consumer's point of view.

The consumer here is SeaBios, right?  To be precise: the specific
version of SeaBios we ship together with QEMU, right?  Then why are our
existing driver names (DevinceInfo member name) not good enough?

>> 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?

What if firmware cares about soundcards as well?