Gleb Natapov <gleb@xxxxxxxxxx> writes:
> On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@xxxxxxxxxx> writes:
>>
>> > 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.
>>
>> "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?
--
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
