31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a misleading name (I originally thought that a
driver could only return 1 when opening an already-existing image
known to be all zeroes; but in reality many drivers always return 1
because it only applies to a just-created image). Refactor all uses
to instead have a single function that returns multiple bits of
information, with better naming and documentation.
Sounds good
No semantic change, although some of the changes (such as to qcow2.c)
require a careful reading to see how it remains the same.
...
diff --git a/include/block/block.h b/include/block/block.h
index 6cd566324d95..a6a227f50678 100644
--- a/include/block/block.h
+++ b/include/block/block.h
Hmm, header file in the middle of the patch, possibly you don't use
[diff]
orderFile = scripts/git.orderfile
in git config.. Or it is broken.
@@ -85,6 +85,28 @@ typedef enum {
BDRV_REQ_MASK = 0x3ff,
} BdrvRequestFlags;
+typedef enum {
+ /*
+ * bdrv_known_zeroes() should include this bit if the contents of
+ * a freshly-created image with no backing file reads as all
+ * zeroes without any additional effort. If .bdrv_co_truncate is
+ * set, then this must be clear if BDRV_ZERO_TRUNCATE is clear.
I understand that this is preexisting logic, but could I ask: why?
What's wrong
if driver can guarantee that created file is all-zero, but is not sure
about
file resizing? I agree that it's normal for these flags to have the same
value,
but what is the reason for this restriction?..