04.02.2019 19:24, Eric Blake wrote: > On 2/4/19 10:03 AM, Vladimir Sementsov-Ogievskiy wrote: > >>>>> What would QMP clients do with this information? >>>> >>>> 'qemu-img info' is the intended QMP client; and it will print the >>>> unknown-flags along with everything else. In other words, we're trying >>>> to make qemu-img become useful for inspecting as much useful information >>>> as possible from an image with unknown origins. Knowing that an image >>>> uses bitmaps with flags unknown to THIS version of qemu is a good >>>> indication that you should be careful about using/altering the image >>>> without first upgrading qemu, as it may destroy data that some other >>>> product desires to utilize. >>> >>> Okay. Now work that into the documentation :) >>> >> >> I'll try: >> >> @unknown-flags: any flags except 'in-use' and 'auto' set for the bitmap. >> Presence of non-zero @unknown-flags definitely shows that >> image was created by newer version of software (which >> supports more bitmap flags) or corrupted. Image can't be >> used for r-w with non-zero @unknown-flags in any bitmap. > > The grammar still feels awkward. Maybe: > > @unknown-flags: If present, this is the value of additional bitmap flags > that were set in the image but not reported in @flags, implying that the > image was created with a newer version of software (that supports new > flags) or has been corrupted. Modifying the image without upgrading qemu > first will likely break the contents of the bitmap. >
Thank you! Oops, hm, I now doubt, how Andrey's patches work, if bitmap_list_load function fails when unknown flags are found. So, can we really show unknown-flags, or we'll fail if there any? And if we fail (I hope we fail) on unknown flags, than we don't need this field :). -- Best regards, Vladimir
