Re: [PATCH for-5.0? v2] qcow2: Explicit mention of padding bytes

[Eric Blake]

On 4/6/20 3:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> 03.04.2020 21:19, Eric Blake wrote:
> > Although we already covered the need for padding bytes with our
> > changes in commit 3ae3fcfa, commit 66fcbca5 just added one byte and
> > relied on the rest of the text for implicitly covering 7 padding
> > bytes.  For consistency with other parts of the header (such as the
> > header extension format listing padding from n - m, or the snapshot
> > table entry mentioning variable padding), we might as well call out
> > the remaining 7 bytes as padding until such time (as any) as they gain
> > another meaning.
> >
> > Signed-off-by: Eric Blake <address@hidden>
> > ---
> >
> > v2: Call out explicit byte range rather than '105 - m' [Max]
> >
> > Safe for 5.0 as it is just a doc fix, but only if we actually want it.
> >
> >   docs/interop/qcow2.txt | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
> > index 640e0eca4000..80728bc2008d 100644
> > --- a/docs/interop/qcow2.txt
> > +++ b/docs/interop/qcow2.txt
> > @@ -210,3 +210,4 @@ version 2.
> >                       Available compression type values:
> >                           0: zlib <https://www.zlib.net/>
> >
> > +        105 - 111:  Padding, leave as zero.
>
> Looking on this in separate, I'd make a software which will zero this 
> padding unconditionally. However, if it's an existing image which we 
> just open, we should keep the content we read.. On the other hand, of 
> course, if read the whole spec, everything is clear.

Maybe:
  105 - 111: Padding, contents defined below

rather than an explicit mention of setting to 0?

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org