Gleb Natapov <g...@redhat.com> writes: > On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote: >> Gleb Natapov <g...@redhat.com> writes: >> >> > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote: >> >> Gleb Natapov <g...@redhat.com> writes: >> >> >> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote: >> >> >> Gleb Natapov <g...@redhat.com> writes: >> >> >> >> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote: >> >> >> >> Gleb Natapov <g...@redhat.com> 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: >> >> >> > /p...@i0cf8/ether...@4/ethernet-...@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 ether...@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". >> > 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.
Nice to have some compatibility, for once. >> > 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). I think we've finally cut through the confusion caused by the unfortunate choice of driver_name for this new device attribute. The fact that you choose values of your driver_name in a way that is inspired by the syntactic conventions of IEEE 1275 is not its distinguishing characteristic. The values of existing member name are inspired by that as well. driver_name's distinguishing characteristic is its purpose: communication with SeaBIOS. I'm fine with you choosing its values however it's convenient for that purpose, as long as you give it a name reflecting that purpose. What about fw_name and qdev_fw_name()? Next, I'm worried about overloading of method get_dev_path(). It's being used for a very specific purpose: savevm/loadvm. * It's currently defined only for PCI devices. Your PATCH 7/8 changes its value there, from DOMAIN:BUS:SLOT.FUNCTION to fw_n...@slot. - The old value identifies the qdev. The new value does not (remember, we have a separate qdev per PCI function). Why is this okay? - Is the value saved with the VM? If yes, this is an incompatible change. * You extend it for ISA and System bus (PATCH 5,6/8). How does this affect savevm? [...] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html