[Top][All Lists]

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

Re: [PATCH v10 1/2] docs: improve qcow2 spec about extending image heade

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v10 1/2] docs: improve qcow2 spec about extending image header
Date: Fri, 31 Jan 2020 16:55:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

20.01.2020 22:42, Eric Blake wrote:
On 1/20/20 11:13 AM, Vladimir Sementsov-Ogievskiy wrote:
Make it more obvious how to add new fields to the version 3 header and
how to interpret them.

The specification is adjusted so for new defined optional fields:

s/so for/so that for/

1. Software may support some of these optional fields and ignore the
    others, which means that features may be backported to downstream
    Qemu independently.
2. If we want to add incompatible field (or a field, for which some its
    values would be incompatible), it must be accompanied by
    incompatible feature bit.

Also the concept of "default is zero" is clarified, as it's strange to
say that the value of the field is assumed to be zero for the software
version which don't know about the field at all and don't know how to
treat it be it zero or not.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
  docs/interop/qcow2.txt | 44 +++++++++++++++++++++++++++++++++++++++---
  1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index af5711e533..355925c35e 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file header:
                      Offset into the image file at which the snapshot table
                      starts. Must be aligned to a cluster boundary.
-If the version is 3 or higher, the header has the following additional fields.
-For version 2, the values are assumed to be zero, unless specified otherwise
-in the description of a field.
+For version 2, the header is exactly 72 bytes in length, and finishes here.
+For version 3 or higher, the header length is at least 104 bytes, including
+the next fields through header_length.
           72 -  79:  incompatible_features
                      Bitmask of incompatible features. An implementation must
@@ -164,6 +164,44 @@ in the description of a field.
          100 - 103:  header_length
                      Length of the header structure in bytes. For version 2
                      images, the length is always assumed to be 72 bytes.
+                    For version 3 it's at least 104 bytes and must be a 
+                    of 8.
+=== Additional fields (version 3 and higher) ===
+In general, these fields are optional and may be safely ignored by the 
+as well as filled by zeros (which is equal to field absence), if software needs

We're inconsistent on 'zeros' (git grep has 201 hits) vs. 'zeroes' (688 hits); 
I prefer the latter, but won't object if you don't tweak it since this is the 
first use of either spelling in qcow2.txt.

No, qcow2.txt already contains 4 invocations of 'zeros' (and no one 'zeroes'), 
so, I'll keep 'zeros' for consitency.

+to set field B, but does not care about field A, which precedes B. More

s/A, which/A which/

+formally, additional fields have the following compatibility rules:
+1. If the value of the additional field must not be ignored for correct
+handling of the file, it will be accompanied by a corresponding incompatible
+feature bit.
+2. If there are no unrecognized incompatible feature bits set, an unknown
+additional field may be safely ignored other than preserving its value when
+rewriting the image header.
+3. An explicit value of 0 will have the same behavior as when the field is not
+present*, if not altered by a specific incompatible bit.
+*. A field is considered not present when header_length is less or equal to the

s/less/less than/

+field's offset. Also, all additional fields are not present for version 2.
+        < ... No additional fields in the header currently ... >
+=== Header padding ===
+@header_length must be a multiple of 8, which means that if the end of the last
+additional field is not aligned, some padding is needed. This padding must be
+zeroed, so that, if some existing (or future) additional field will fall into

s/that, if/that if/

+the padding, it will be interpreted accordingly to point [3.] of the previous
+paragraph, i.e.  in the same manner as when this field is not present.
+=== Header extensions ===
  Directly after the image header, optional sections called header extensions 
  be stored. Each extension has a structure like the following:

We're down to few enough grammar nits that I'm happy with:

Reviewed-by: Eric Blake <address@hidden>

Best regards,

reply via email to

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