25.06.2020 18:21, Max Reitz wrote:
There are BDS children that the general block layer code can access,
namely bs->file and bs->backing. Since the introduction of filters and
external data files, their meaning is not quite clear. bs->backing can
be a COW source, or it can be a filtered child; bs->file can be a
filtered child, it can be data and metadata storage, or it can be just
metadata storage.
This overloading really is not helpful. This patch adds functions that
retrieve the correct child for each exact purpose. Later patches in
this series will make use of them. Doing so will allow us to handle
filter nodes in a meaningful way.
Signed-off-by: Max Reitz <mre...@redhat.com>
---
include/block/block_int.h | 44 +++++++++++++++++--
block.c | 90 +++++++++++++++++++++++++++++++++++++++
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 1b86b59af1..bb3457c5e8 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
[..]
+/*
+ * If @bs acts as a filter for exactly one of its children, return
+ * that child.
+ */
+BdrvChild *bdrv_filter_child(BlockDriverState *bs)
Hmm you called it filter_child instead of filterED_child..
+{
+ BdrvChild *c;
+
+ if (!bs || !bs->drv) {
+ return NULL;
+ }
+
+ if (!bs->drv->is_filter) {
+ return NULL;
+ }
+
+ /* Only one of @backing or @file may be used */
+ assert(!(bs->backing && bs->file));
+
+ c = bs->backing ?: bs->file;
+ if (!c) {
+ return NULL;
+ }
+
+ assert(c->role & BDRV_CHILD_FILTERED);
But the role is still called CHILD_FILTERED
+ return c;
+}
(just note that it's a bit inconsistent, keep my r-b anyway)
--
Best regards,
Vladimir
