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

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

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 <eblake@redhat.com>
> ---
> 
> 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.


-- 
Best regards,
Vladimir