On Sun, 2009-05-31 at 17:47 +0300, Dor Laor wrote:
Mark McLoughlin wrote:
On Fri, 2009-05-29 at 10:43 +0100, Mark McLoughlin wrote:
The more I think about it, no matter how much linear ABI versioning
sucks, it's possibly the only way to solve this in a reasonably usable
manners. Distros would just have to suck it up and agree that if they
cherry-pick an ABI changing patch, they must update the entire ABI to
the newer upstream ABI version.
Okay, how about this:
- Add a saveabi monitor command
- Whenever libvirt starts a guest or hotplugs a device, it executes
saveabi and retains the output
- The abi can be restored with qemu -loadabi or the loadabi monitor
command
- The abi file doesn't describe the device model, it merely gives
hints for building the device model which is described on the
command line
- If the abi file contains details of a device which is not listed on
the command line, it's just ignored and not included in the next
saveabi
- If the abi file is missing details of a device which is listed on
the command line, the device is constructed using the defaults and
included in the next saveabi
- This means the abi file is opaque to the management tools - unlike
the machine config file, libvirt would not need to modify it when
devices are added or removed by the user
IMO it shouldn't be opaque
The important requirement is that management tools should never need to
modify saveabi output.
and we might use the same config file for the abi too.
What we don't want is:
$> qemu -config guest.config
where guest.config contains both details of which devices are needed
*and* what their ABI should be.
We want:
$> qemu -loadabi guest.abi -config guest.confg
or:
$> qemu -loadabi guest.abi -drive ... -net ... -serial ...
The idea being that we should not mix up ABI requirements with device
configuration.
The management tools do not need to know the details of the ABI
provided, they just want to request qemu to use the same ABI as was used
previously.
Put more simply - with saveabi/loadabi, the management tools would not
need to know that older versions of qemu's virtio-console used
PCI_CLASS_DISPLAY_OTHER.
The notion of abi config is indeed required and most of the times, mgmt
tools won't need to deal with it.
But, let's say for instance that the user with certain abi configs, now
change some existence of pci device, bios memory mapping, etc. In the
case mgmt should automatically adjust both config files to minimize
the effect on the guest and not to create a conflict.
I think that would defeat a lot of the value of this. It adds an awful
lot of complexity to the management tools.
The device config file should always just take precedence and the abi
file should just be used as hints to allow the same ABI to be used. If
e.g. a device is removed, the hints for that device can be ignored and
dropped in the next saveabi.
Cheers,
Mark.