From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure. Date: Fri, 05 Nov 2010 17:24:01 +0100 Message-ID: References: <1288525209-3303-1-git-send-email-gleb@redhat.com> <1288525209-3303-2-git-send-email-gleb@redhat.com> <20101104094244.GC6018@redhat.com> <20101104154454.GB14910@redhat.com> <20101105154142.GA9617@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: blauwirbel@gmail.com, alex.williamson@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44435 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752692Ab0KEQYG (ORCPT ); Fri, 5 Nov 2010 12:24:06 -0400 In-Reply-To: <20101105154142.GA9617@redhat.com> (Gleb Natapov's message of "Fri, 5 Nov 2010 17:41:42 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov writes: > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote: >> Gleb Natapov writes: >> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote: >> >> Gleb Natapov writes: >> >> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote: >> >> >> Gleb Natapov 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?