On Sat, Nov 06, 2010 at 10:01:25AM +0100, Markus Armbruster wrote: [skip] > > 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. > My understanding of this name in IEEE 1275 is that it specifies what driver in FW handles a device. > 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()? > I am not attached to the name. Can "alias" be used for that purpose? > > Next, I'm worried about overloading of method get_dev_path(). It's > being used for a very specific purpose: savevm/loadvm. > This part of the patch is not completed yet. I intend to change the code in savevm/loadvm to call qdev_get_dev_path() to get full device path there. > * It's currently defined only for PCI devices. Your PATCH 7/8 changes > its value there, from DOMAIN:BUS:SLOT.FUNCTION to FW_NAME@SLOT. > Old definition is buggy BTW. BUS part is controlled by a guest and may be different from default value at destination. > - The old value identifies the qdev. The new value does not > (remember, we have a separate qdev per PCI function). Why is this > okay? > No no. New value is FW_NAME@SLOT,FUNC. Spec says that if FUNC is zero it can be omitted. > - Is the value saved with the VM? If yes, this is an incompatible > change. Don't understand that remark. > > * You extend it for ISA and System bus (PATCH 5,6/8). How does this > affect savevm? > We should ask savevm experts. As far as I can see it affects id creation. As long as id is unique we should be OK. We may send more info on migration after the patches. -- Gleb. -- 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
