All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: Alberto Garcia <berto@igalia.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Eric Blake <eblake@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Intermediate block mirroring
Date: Thu, 3 May 2018 14:22:41 +0200	[thread overview]
Message-ID: <20180503122241.GA6140@localhost.localdomain> (raw)
In-Reply-To: <aab201a7-ef3f-8152-cc37-85ae7e106a5e@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

Am 02.05.2018 um 16:12 hat Max Reitz geschrieben:
> On 2018-05-02 15:07, Alberto Garcia wrote:
> > Were the (more or less) exact requirements of QMP blockdev-reopen
> > discussed? How is it different from qemu-io's "reopen" command? What are
> > the options that you can and can not change?
> 
> I can't quite remember, I'm afraid.  I think it was supposed to be
> pretty much qemu-io's reopen (so just bdrv_reopen()).  I suppose you
> cannot change the driver (obviously) or probably the node name, because
> either would result in the node being replaced by a completely new one.
> 
> Other than that, it probably depends on what the block driver supports,
> but ideally you should be able to change everything.

Honestly the design of bdrv_reopen() is quite broken because of the way
it tries to maintain old options if they aren't specified, and guesses
what you might mean when you add flags to the mix. The exact semantics
are quite complicated and I'd rather avoid them in a stable API.

A clean QMP command would probably apply the same defaults as
blockdev-add, so you just get to specify the full options again.

> reopen: You call it like blockdev-add, that is:
>     { "node-name": "overlay",
>       "backing": "new-backing" }
> In theory every option you do not specify is unchanged, so I suppose you
> can leave out e.g. the "driver" option here.

That already doesn't work because "driver" is the discriminator for the
QAPI union, so it must be mandatory. I'd go further and reuse
BlockdevOptions, which makes everything mandatory that is mandatory when
creating the image.

blockdev-reopen would basically mean "replace the whole set of options
of this node".

> Sure, with reopen you can also respecify the whole tree if you so desire
> (so you can get away without blockdev-add'ing new-backing before), but
> you don't have to.

It might be reasonable to forbid inline declarations for BlockdevRef in
blockdev-reopen, so that always have to specify node names instead. On
the other hand, maybe support for inline declarations falls out almost
automatically.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  parent reply	other threads:[~2018-05-03 12:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 17:07 [Qemu-devel] [RFC] Intermediate block mirroring Alberto Garcia
2018-04-13 14:23 ` Max Reitz
2018-04-16 14:59   ` Alberto Garcia
2018-04-16 15:15     ` Max Reitz
2018-04-18 15:34       ` Alberto Garcia
2018-04-20 13:13         ` Max Reitz
2018-04-25 12:58           ` Alberto Garcia
2018-04-25 13:06             ` Max Reitz
2018-04-25 13:42               ` Alberto Garcia
2018-04-25 14:03                 ` Max Reitz
2018-05-02 13:07                   ` Alberto Garcia
2018-05-02 14:12                     ` Max Reitz
2018-05-03 10:32                       ` Alberto Garcia
2018-05-03 12:22                       ` Kevin Wolf [this message]
2018-05-03 12:33                         ` Alberto Garcia
2018-05-09 14:22                         ` Alberto Garcia
2018-06-01 10:51                         ` Alberto Garcia
2018-06-11 12:20                           ` Kevin Wolf
2018-06-11 12:23                             ` Alberto Garcia
  -- strict thread matches above, loose matches on Subject: below --
2015-04-02 13:28 Alberto Garcia
2015-04-02 16:56 ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180503122241.GA6140@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.