"Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: > On Mon, Aug 05, 2013 at 08:28:50AM -0500, Anthony Liguori wrote: >> "Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: >> >> > On Mon, Aug 05, 2013 at 12:18:10PM +0100, Peter Maydell wrote: >> >> This patch series adds a 'virt' platform which uses the >> >> kernel's mach-virt (fully device-tree driven) support >> >> to create a simple minimalist platform intended for >> >> use for KVM VM guests. It's based on John Rigby's >> >> patches, but I've overhauled it a lot: >> > >> > On x86, we've long had versioned machine names, so that we can >> > make changes in future QEMU releases without breaking guest ABI >> > compatibility. AFAICT, the problem has basically been ignored >> > on non-x86 platforms in QEMU. Given the increased interest in >> > ARM in particular, should we use the addition of this new 'virt' >> > machine type, as an opportunity to introduce versioning for >> > ARM too. eg make this machine be called 'virt-1.0.6' and then >> > have 'virt' simply be an alias that points to the most recent >> > version. >> >> I've been thinking about this for SPAPR too. Like virt, I'm not sure >> the platform is stable enough for this but I expect it to be soon. > > BTW, do you have any tests / scripts you use to validate the machine > type stability prior to cutting releases ? I use qemu-test which has a finger printing test for this purpose. > > Seems like it ought to be able to have some custom initrd which > just recorded contents of various sysfs/procfs files & perhaps PCI > device config space blobs. That's exactly what it does in fact. > Then just boot the QEMU release candidate > binaries with this initrd & compare the results to previously recorded > data, for each machine type ? If the records for each machine type > were checked into GIT, you could arguably do this as part of 'make test' > so developers can see if something they're doing is breaking ABI by > mistake. > >> However, unlike PC, I'd like to do linear versioning and avoid bumping >> at every release. >> >> IOW, spapr-1, spapr-2, spapr-3, etc. >> >> I think virt ought to try to do the same. > > Any particular reason why ? I kind of like the clarity of having the > version match the release version. Avoids needing to lookup a magic > decoder ring to figure out which QEMU version maps to which machine > version. (1) reduces testing matrix by having fewer versions (2) makes people think more carefully about whether it's really necessary to break compatibility. > Would you say that stable release branches should not accept any > patch that changes guest ABI, to avoid this single component version > number turning into a 2 component version on stable branches ? Yes. This is already the policy FWIW. Regards, Anthony Liguori > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
