qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/1] qemu-img: Add "backing":true to unallocated map segme


From: Nir Soffer
Subject: Re: [PATCH v2 2/1] qemu-img: Add "backing":true to unallocated map segments
Date: Tue, 29 Jun 2021 18:53:12 +0300

On Tue, Jun 29, 2021 at 5:40 PM Kevin Wolf <kwolf@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]