All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
	qemu-block@nongnu.org, Jeff Cody <jcody@redhat.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Alberto Garcia <berto@igalia.com>, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] Minutes from the "Stuttgart block Gipfele"
Date: Wed, 23 Dec 2015 16:33:43 +0800	[thread overview]
Message-ID: <20151223083343.GB8461@stefanha-x1.localdomain> (raw)
In-Reply-To: <87vb7vc2yt.fsf@blackfin.pond.sub.org>

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

On Fri, Dec 18, 2015 at 02:15:38PM +0100, Markus Armbruster wrote:
> What should happen when the user asks for a mutation at a place where we
> have implicit filter(s)?

Please suspend your disbelief for a second:

In principle it's simplest not having implicit filters.  The client
needs to set up throttling nodes or the backup filter explicitly.

Okay, now it's time to tear this apart:

For backwards compatibility it's necessary to support throttling,
copy-on-read, backup notifier, etc.  It may be possible to tag implicit
filter nodes so that mutation operations that wouldn't be possible today
are rejected.  The client must use the explicit syntax to do mutations
on implicit filters.  This is easier said than done, I'm not sure it can
be implemented cleanly.

Another problem is that the backup block job and other operations that
require a single command today could require sequences of low-level
setup commands to create filter nodes.  The QMP client would need to
first create a write notifier filter and then start the backup block job
with the write notifier node name.  It's clumsy.

Stefan

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

  reply	other threads:[~2015-12-23  8:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18 13:15 [Qemu-devel] Minutes from the "Stuttgart block Gipfele" Markus Armbruster
2015-12-23  8:33 ` Stefan Hajnoczi [this message]
2016-01-11 15:10   ` Kevin Wolf
2016-01-14 11:25     ` Stefan Hajnoczi
2015-12-23 10:15 ` Fam Zheng
2016-01-04  5:16   ` Stefan Hajnoczi
2016-01-04  7:28     ` Fam Zheng
2016-01-07  5:23       ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-01-07  9:32         ` Fam Zheng

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=20151223083343.GB8461@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.com \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.