Peter Krempa <pkre...@redhat.com> writes: > On Mon, Mar 11, 2019 at 15:10:36 -0500, Eric Blake wrote: >> On 3/11/19 2:59 PM, Peter Krempa wrote: >> >> >> auto-read-only was introduced in 3.1, at which point we intentionally >> >> had sufficiently loose wording to permit (but not require) dynamic state >> >> checking; so you are not breaking the interface. On the other hand, is >> >> libvirt going to have problems introspecting whether it can use >> >> auto-read-only and get the dynamic behavior it needs? Or is there >> >> enough else in the way of libvirt's switch to -blockdev that it won't >> >> attempt anything that needs auto-read-only without other 4.0 interfaces >> >> anyway, at which point detecting the presence of the field (but not >> >> whether the field has a guarantee of dynamic behavior) on 3.1 doesn't >> >> matter? >> > >> > I think we can use Stefan's capability detection mechanism he introduced >> > for the migration with cache enabled for local files to add a flag for >> > this as well. >> >> Except I thought we decided that the most recent version of his QMP >> changes was now fully-introspectible, thanks to using conditional >> compilation. >> >> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02510.html > > Oh, bummer, I missed that it was no longer needed. I still think it's > worth adding that for future use once it will be necessary to detect > that certain things were patched and require libvirt to change behaviour > if that's the case.
We'll add it when we have a compelling use for it. >> Well, that may prove to be a short-lived hiatus, if libvirt would >> happily attempt to use qemu 3.1 and fail without some other >> introspectible hook to know whether auto-read-only has required semantics.
