On 2/4/19 11:33 AM, Eric Blake wrote: > On 2/4/19 10:46 AM, Vladimir Sementsov-Ogievskiy wrote: > >>> >>> 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 :). >>> >> >> But we can update bitmap_list_load, to have a flag, and show bitmaps with >> unknown flags in qemu-img info.. And we have to somehow not fail on open >> before >> it. I'm very sorry that I understand it all only now :(. >> >> So, do we really need unknown-flags field? If yes, may be, do it as a next >> step? >> And proceed now without them? > > Good point about not even being able to open an image with unknown flags > to be able to report on it (qemu-img check might want to be able to do > it, but if qemu-img info refuses to open the image because of unknown > flags, that's acceptable). I'm good with your idea of skipping > unknown-flags for now, and adding it in a later patch if it proves > worthwhile.
It may also be worth an addition to iotests that intentionally corrupts an image with persistent bitmaps to set an unknown bit, just to see how qemu reacts to such an image. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
