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

[Gleb Natapov]

On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote:
> 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".
> 
It is impossible to figure what i440FX is. Anyway as I said many times
already device path shouldn't contain full information about all devices
in the path but only enough information to find device the path points
to. FDT contains full information about device including all resources
it uses, full device name, compatible device list an so on. This patch
is not about passing FDT to FW, just about creating Open Firmware
complaint device path.

> 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?
> 
AFAIK all PC chipsets implement same PCI config interface accessible
through io ports 0cf8-0cff. Otherwise each OS will have to have support
for each chipset.

> >                          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?
> 
Why should Seabios match against three (or even more) different type of
devices to detect ata interface? Why require Seabios changes when this
can be avoided (if new device that provide ata is added)? OpenBIOS also
supports qemu BTW (this is Open Firmware implementation for pc, you can
run and see what kind of device paths it generates). 

> >> 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?
Then I expect device hierarchy reflect the fact that one device provides
two different devices one of which is ata and another one is soundcard.
Or are you suggesting that the same ISA card provides ata and soundcard
functionality through the same IO ports? Then don't call it ata. Call is
something else like ACME,atablaster. It will have to have special
support in firmware anyway.

--
                        Gleb.