qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 01/37] blockdev: Allow creation of BDS trees


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v2 01/37] blockdev: Allow creation of BDS trees without BB
Date: Wed, 04 Mar 2015 09:23:22 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 2015-03-04 at 09:15, Kevin Wolf wrote:
Am 04.03.2015 um 15:04 hat Max Reitz geschrieben:
On 2015-03-04 at 08:39, Kevin Wolf wrote:
Am 09.02.2015 um 18:11 hat Max Reitz geschrieben:
If the "id" field is missing from the options given to blockdev-add,
just omit the BlockBackend and create the BlockDriverState tree alone.

However, if "id" is missing, "node-name" must be specified; otherwise,
the BDS tree would no longer be accessible.

Signed-off-by: Max Reitz <address@hidden>
---
  blockdev.c                 | 44 +++++++++++++++++++++++++++++++-------------
  qapi/block-core.json       | 13 +++++++++----
  tests/qemu-iotests/087     |  2 +-
  tests/qemu-iotests/087.out |  4 ++--
  4 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 6eedcf5..6d67c80 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2822,17 +2822,12 @@ out:
  void qmp_blockdev_add(BlockdevOptions *options, Error **errp)
  {
      QmpOutputVisitor *ov = qmp_output_visitor_new();
-    BlockBackend *blk;
+    BlockDriverState *bs;
+    BlockBackend *blk = NULL;
      QObject *obj;
      QDict *qdict;
      Error *local_err = NULL;
-    /* Require an ID in the top level */
-    if (!options->has_id) {
-        error_setg(errp, "Block device needs an ID");
-        goto fail;
-    }
-
      /* TODO Sort it out in raw-posix and drive_new(): Reject aio=native with
       * cache.direct=false instead of silently switching to aio=threads, except
       * when called from drive_new().
@@ -2860,14 +2855,37 @@ void qmp_blockdev_add(BlockdevOptions *options, Error 
**errp)
      qdict_flatten(qdict);
-    blk = blockdev_init(NULL, qdict, &local_err);
-    if (local_err) {
-        error_propagate(errp, local_err);
-        goto fail;
+    if (options->has_id) {
+        blk = blockdev_init(NULL, qdict, &local_err);
+        if (local_err) {
+            error_propagate(errp, local_err);
+            goto fail;
+        }
+
+        bs = blk_bs(blk);
+    } else {
+        int ret;
+
+        if (!qdict_get_try_str(qdict, "node-name")) {
+            error_setg(errp, "'id' and/or 'node-name' need to be specified for 
"
+                       "the root node");
+            goto fail;
+        }
+
+        bs = NULL;
+        ret = bdrv_open(&bs, NULL, NULL, qdict, BDRV_O_RDWR | BDRV_O_CACHE_WB,
+                        NULL, errp);
Now all the qdict entries that aren't parsed by bdrv_open() but
converted into flags by blockdev_init() are broken if you don't give an
id. This includes read-only, discard, the cache options - in other
words, enough to make this "support" completely useless.
See patch 23.
No matter what I'll find there (okay, I've cheated and already quickly
looked at it before writing this), this answer tells me that you're
doing things in the wrong order.

To cite the cover letter of v1 regarding the patch order, here for patches 1 and 2:

> Patches 35 [22] and 36 [23] are kind of a follow-up to these; but
> patch 35 [22] depends on patch 34 [21] which is the reason why there
> is a large gap between patch 2 and 35 [22].

I remember needing patch 2 before the rest. Maybe I don't which means I can move it back. I'll see.

My reasoning is the following: Yes, blockdev-add for BB-less BDS trees is nearly unusable after this. But it's enough for patch 2; and it does not break anything, because trying that simply always threw an error before this patch. Afterwards, only most usages will result in an error, but the ones introduced in patch 2 are fine. And patch 23 then "unlocks" all useful usages (that I can see). So nothing breaks at any point, we're only slowly allowing more use cases (and everything contained within a single series).

Max



reply via email to

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