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.