On Tue, Jun 29, 2021 at 5:40 PM Kevin Wolf <kw...@redhat.com> wrote: > > Am 29.06.2021 um 09:23 hat Vladimir Sementsov-Ogievskiy geschrieben: > > 28.06.2021 20:42, Eric Blake wrote: > > > On Wed, Jun 23, 2021 at 06:04:19PM +0200, Kevin Wolf wrote: > > > > > This is fine, but it means that this flag will present in all ranges, > > > > > instead of only in unallocated ranges (what this patch is doing). > > > > > > > > An argument for always having the flag would be that it's probably > > > > useful for a tool to know whether a given block is actually absent or > > > > whether it's just running an old qemu-img. > > > > > > > > If we didn't care about this, I would still define the actual value, but > > > > also document a default. > > > > > > So to summarize, it looks like my v3 will have the best chance of > > > approval if I go with always outputting the new field (instead of only > > > on one of its two boolean values), and put it at the end of the JSON > > > output.
Since the "present" key is always present, it does not need to be at the end. > > > It also looks like we have consensus on spelling the new > > > field "present":true for data found in the backing chain, and > > > "present":false for places where we would defer to another file if a > > > backing file is later added. > > > > > > > I didn't follow the discussion carefully, but that sounds good to me. > > To me, too. > > > What's the decision about patch 1? > > I think we won't need patch 1 (and the potential backwards compatibility > problems it would introduce) when we have this one. Yes, looks good and patch 1 is not needed. Nir