On 01/12/2016 05:10 PM, Fam Zheng wrote: >> If we will switch default in my patch from 'nolock' to 'lock' then >> pour guys which are calling qemu-img etc stuff will see the lock >> as necessary while 'proper management software' aka libvirt >> will be able to call qemu/qemu-img etc with proper 'nolock' >> flag as they do care about the locking. > > That is wrong because then we break old libvirt with the new qemu-img > (acquires > lock by default), which is IMO a breakage of backward compatibility.
In the big software stack picture, it is okay to reject 'old libvirt/new qemu' as an invalid combination. Upgrade-wise, we specifically support 'new libvirt/old qemu' - but it is fair game to say that 'if you want to run new qemu, you must first upgrade to new libvirt that knows how to drive it'. That said, minimizing back-compat breaks, so that old libvirt can (usually) correctly drive new qemu, is a worthy design goal for qemu. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
