On Wed, 2010-06-09 at 21:36 +0100, Paul Brook wrote: > > > Not really. This identifier is device and bus independent, which is why > > > I suggested passing the device to qemu_ram_alloc. This can then figure > > > out how to the identify the device. It should probably do this the same > > > way that we identify the saved state for the device. Currently I think > > > this is an arbitrary vmstate name/id, but I expect this to change to a > > > qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0"). > > > > Ok, that seems fairly reasonable, so from a device pointer we can get > > something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add > > something like ":rom" or ":bar.0" to it via an extra string. > > > > qemu_ram_alloc(DeviceState *dev, const char *info, size) > > Exactly - though personally I wouldn't call the second argument "info". Hmm, this gets a little hairy for patch 5/6 where we try to create a block on the fly to match the migration source. For now, this is mainly to catch things like devices that are hot plugged then removed before migration, but don't currently have a functional qemu_ram_free() to clean up. However, if we could get past that and clean up drivers, it might be nice for the string to provide enough information to instantiate the missing device on the target. I suddenly see that char[64] name becoming insufficient. Maybe we should follow the vmstate example and use a variable length string preceded by a length byte (or two). Alex -- 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
