From: Max Reitz <mreitz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Peter Lieven <pl@kamp.de>,
Markus Armbruster <armbru@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/5] block: Add AioContextNotifier functions to BB
Date: Tue, 18 Nov 2014 10:26:36 +0100 [thread overview]
Message-ID: <546B10CC.5040408@redhat.com> (raw)
In-Reply-To: <546A2FD0.3090907@redhat.com>
On 2014-11-17 at 18:26, Paolo Bonzini wrote:
> On 17/11/2014 16:30, Max Reitz wrote:
>> Because all BlockDriverStates behind a single BlockBackend reside in a
>> single AioContext, it is fine to just pass these functions
>> (blk_add_aio_context_notifier() and blk_remove_aio_context_notifier())
>> through to the root BlockDriverState.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
> The logical question then is: are there any function in BlockDriverState
> that do not make sense as a BlockBackend API?
Well, surely bdrv_swap(), or bdrv_drop_intermediate(). These are
functions which work on multiple BDSs (in the same tree, that is, behind
the same BB) so they don't make sense on the BB.
Others could simply be passed through to the root BDS but it somehow
doesn't make sense to execute them on the BB. For instance,
bdrv_set_key(); this is something for an individual BDS, in contrast to
other operations like reading and writing which will probably be passed
through the BDS tree; or bdrv_get_info().
The functions added in this patch do make sense on a BB level: Since all
BDSs behind one BB are always in the same AioContext, it makes sense to
consider that the BB's AioContext.
The next patch is more difficult to justify. Closing a BDS is somehow
passed through, but at first glance it doesn't make a whole lot of sense
on the BB level. However, when you consider (as far as I looked into it)
that a BDS is only closed when there are either no references to it
(which will not happen as long as it has a BB) or when it is ejected, it
suddenly does make sense: "Ejecting" really is something for the BB, so
it makes sense to wait for that event (even though the name "close
notifier" doesn't sound much like it...). Maybe I should sometimes take
a deeper look into when a BDS belonging to a BB may be closed and if
it's really only due to ejection, rename the "close notifiers" to
something like "eject notifiers" (on the BB level).
Max
next prev parent reply other threads:[~2014-11-18 9:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 15:30 [Qemu-devel] [PATCH 0/5] nbd: Use BlockBackend Max Reitz
2014-11-17 15:30 ` [Qemu-devel] [PATCH 1/5] block: Lift more functions into BlockBackend Max Reitz
2014-11-17 15:30 ` [Qemu-devel] [PATCH 2/5] block: Add AioContextNotifier functions to BB Max Reitz
2014-11-17 17:26 ` Paolo Bonzini
2014-11-18 9:26 ` Max Reitz [this message]
2014-11-18 9:44 ` Paolo Bonzini
2014-11-17 15:30 ` [Qemu-devel] [PATCH 3/5] block: Add blk_add_close_notifier() for BB Max Reitz
2014-11-17 15:30 ` [Qemu-devel] [PATCH 4/5] nbd: Change external interface to BlockBackend Max Reitz
2014-11-17 15:30 ` [Qemu-devel] [PATCH 5/5] nbd: Use BlockBackend internally Max Reitz
2014-11-17 17:29 ` Paolo Bonzini
2014-11-18 9:32 ` Max Reitz
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=546B10CC.5040408@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pl@kamp.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).