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.