On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote: > Avi Kivity wrote: > > On 06/15/2009 12:09 PM, Mark McLoughlin wrote: > >>>>> I think the point is that you don't need version numbers if you > >>>>> have a > >>>>> proper device tree. > >>>>> > >>>>> > >>>> How do you add a new attribute to the device tree and, when a supplied > >>>> device tree lacking said attribute, distinguish between a device tree > >>>> from an old version of qemu (i.e. use the old default) and a partial > >>>> device tree from the VM manager (i.e. use the new default) ? > >>>> > >>>> > >>> -baseline 0.10 > >>> > >> > >> That's a version number :-) > >> > >> (I was responding to Anthony's "you don't need a version number") > >> > > > > If you want to prevent incompatibilities, you need to make everything > > new (potentially including bugfixes) non-default. No need to punish new guests in order to maintain compatibility for old guests. > > Eventually the > > default configuration becomes increasingly unusable and you need a new > > baseline. You must still be able to fall back to the old baseline for > > older guests. I don't think games with configuration files can hide > > that. > > -M pc1 > -M pc2 > > etc. > > This is pretty easy to maintain with config files. I think this would be reasonable, but it is essentially just a version number which you objected to on the basis that it would make cherry-picking harder for distros. One thing that would be nice with this '-M pc1' thing would be to retain '-M pc' as a symlink to the latest version. We'd also need a way to read the symlink too, so that you can query what the current latest version is and use that in future. How would this machine type version relate to e.g. changing the default PCI class of virtio-blk? Would we bump the version number of all machine types can use virtio-blk? A per-device version number is workable alternative, but only with a saveabi type file IMHO. I've tried to summarise the options here: https://fedoraproject.org/wiki/Features/KVM_Stable_Guest_ABI Cheers, Mark. -- 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
