From: Max Reitz <mreitz@redhat.com>
To: Alberto Garcia <berto@igalia.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
Eric Blake <eblake@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitrary node
Date: Wed, 27 Apr 2016 14:30:55 +0200 [thread overview]
Message-ID: <5720B0FF.6070605@redhat.com> (raw)
In-Reply-To: <fc8559ce754d2679924881b76d1a6993041bcdf4.1459776815.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 4359 bytes --]
On 04.04.2016 15:43, Alberto Garcia wrote:
> Currently, block jobs can only be owned by root nodes. This patch
> allows block jobs to be in any arbitrary node, by making the following
> changes:
>
> - Block jobs can now be identified by the node name of their
> BlockDriverState in addition to the device name. Since both device
> and node names live in the same namespace there's no ambiguity.
>
> - The "device" parameter used by all commands that operate on block
> jobs can also be a node name now.
>
> - The node name is used as a fallback to fill in the BlockJobInfo
> structure and all BLOCK_JOB_* events if there is no device name for
> that job.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> blockdev.c | 18 ++++++++++--------
> blockjob.c | 5 +++--
> docs/qmp-events.txt | 8 ++++----
> qapi/block-core.json | 20 ++++++++++----------
> 4 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index edbcc19..d1f5dfb 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -3685,8 +3685,10 @@ void qmp_blockdev_mirror(const char *device, const char *target,
> aio_context_release(aio_context);
> }
>
> -/* Get the block job for a given device name and acquire its AioContext */
> -static BlockJob *find_block_job(const char *device, AioContext **aio_context,
> +/* Get the block job for a given device or node name
> + * and acquire its AioContext */
> +static BlockJob *find_block_job(const char *device_or_node,
> + AioContext **aio_context,
> Error **errp)
> {
> BlockBackend *blk;
> @@ -3694,18 +3696,18 @@ static BlockJob *find_block_job(const char *device, AioContext **aio_context,
>
> *aio_context = NULL;
>
> - blk = blk_by_name(device);
> - if (!blk) {
> + bs = bdrv_lookup_bs(device_or_node, device_or_node, errp);
> + if (!bs) {
If we get here, *errp is already set... [1]
> goto notfound;
> }
>
> - *aio_context = blk_get_aio_context(blk);
> + *aio_context = bdrv_get_aio_context(bs);
> aio_context_acquire(*aio_context);
>
> - if (!blk_is_available(blk)) {
> + blk = blk_by_name(device_or_node);
> + if (blk && !blk_is_available(blk)) {
I'd just drop this. The reason blk_is_available() was added here because
it became possible for BBs not to have a BDS.
Now that you get the BDS directly through bdrv_lookup_bs(), it's no
longer necessary.
> goto notfound;
> }
> - bs = blk_bs(blk);
>
> if (!bs->job) {
> goto notfound;
> @@ -3715,7 +3717,7 @@ static BlockJob *find_block_job(const char *device, AioContext **aio_context,
>
> notfound:
> error_set(errp, ERROR_CLASS_DEVICE_NOT_ACTIVE,
> - "No active block job on device '%s'", device);
> + "No active block job on node '%s'", device_or_node);
[1] ...and then we'll get a failed assertion here (through error_setv()).
> if (*aio_context) {
> aio_context_release(*aio_context);
> *aio_context = NULL;
> diff --git a/blockjob.c b/blockjob.c
> index 3557048..2ab4794 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -67,7 +67,8 @@ void *block_job_create(const BlockJobDriver *driver, BlockDriverState *bs,
> BlockJob *job;
>
> if (bs->job) {
> - error_setg(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
> + error_setg(errp, "Node '%s' is in use",
> + bdrv_get_device_or_node_name(bs));
> return NULL;
> }
> bdrv_ref(bs);
> @@ -78,7 +79,7 @@ void *block_job_create(const BlockJobDriver *driver, BlockDriverState *bs,
> bdrv_op_unblock(bs, BLOCK_OP_TYPE_DATAPLANE, job->blocker);
>
> job->driver = driver;
> - job->id = g_strdup(bdrv_get_device_name(bs));
> + job->id = g_strdup(bdrv_get_device_or_node_name(bs));
Hm, since this is only used for events, it's not too bad that a block
job will have a different name if it was created on a root BDS by
specifying its node name. But it still is kind of strange.
But as I said, it should be fine as long as one can still use the node
name for controlling it (which is the case).
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-04-27 12:31 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 13:43 [Qemu-devel] [PATCH for-2.7 v9 00/11] Support streaming to an intermediate layer Alberto Garcia
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 01/11] block: keep a list of block jobs Alberto Garcia
2016-04-27 11:59 ` Max Reitz
2016-04-29 14:22 ` Kevin Wolf
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 02/11] block: use the block job list in bdrv_drain_all() Alberto Garcia
2016-04-27 12:04 ` Max Reitz
2016-04-27 12:08 ` Alberto Garcia
2016-04-29 14:25 ` Kevin Wolf
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 03/11] block: use the block job list in qmp_query_block_jobs() Alberto Garcia
2016-04-27 12:09 ` Max Reitz
2016-04-29 14:32 ` Kevin Wolf
2016-05-02 13:06 ` Alberto Garcia
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 04/11] block: use the block job list in bdrv_close() Alberto Garcia
2016-04-27 12:14 ` Max Reitz
2016-04-29 14:38 ` Kevin Wolf
2016-05-02 13:42 ` Alberto Garcia
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitrary node Alberto Garcia
2016-04-27 12:30 ` Max Reitz [this message]
2016-04-27 14:59 ` Alberto Garcia
2016-04-29 15:00 ` Kevin Wolf
2016-05-06 10:00 ` Alberto Garcia
2016-05-06 17:54 ` John Snow
2016-05-09 7:06 ` Kevin Wolf
2016-05-09 11:59 ` Alberto Garcia
2016-04-29 15:25 ` Eric Blake
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 06/11] block: Support streaming to an intermediate layer Alberto Garcia
2016-04-27 13:04 ` Max Reitz
2016-04-28 9:23 ` Alberto Garcia
2016-04-29 15:07 ` Kevin Wolf
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 07/11] block: Add QMP support for " Alberto Garcia
2016-04-27 13:34 ` Max Reitz
2016-04-28 12:20 ` Alberto Garcia
2016-04-29 15:18 ` Kevin Wolf
2016-05-03 12:50 ` Alberto Garcia
2016-05-03 13:23 ` Kevin Wolf
2016-05-03 13:33 ` Alberto Garcia
2016-05-03 13:48 ` Kevin Wolf
2016-05-03 15:09 ` Alberto Garcia
[not found] ` <w517fezo0al.fsf@maestria.local.igalia.com>
2016-05-12 15:04 ` Kevin Wolf
[not found] ` <w514ma3nwbl.fsf@maestria.local.igalia.com>
2016-05-12 15:28 ` Kevin Wolf
2016-05-17 14:26 ` Alberto Garcia
2016-05-17 14:47 ` Kevin Wolf
2016-05-17 14:54 ` Alberto Garcia
2016-04-29 15:11 ` Kevin Wolf
2016-05-03 12:53 ` Alberto Garcia
2016-05-03 13:18 ` Kevin Wolf
2016-05-03 13:29 ` Alberto Garcia
2016-04-29 15:29 ` Eric Blake
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 08/11] docs: Document how to stream " Alberto Garcia
2016-04-04 13:43 ` [Qemu-devel] [PATCH v9 09/11] qemu-iotests: test streaming " Alberto Garcia
2016-04-04 13:44 ` [Qemu-devel] [PATCH v9 10/11] qemu-iotests: test overlapping block-stream operations Alberto Garcia
2016-04-27 13:48 ` Max Reitz
2016-04-27 15:02 ` Alberto Garcia
2016-04-04 13:44 ` [Qemu-devel] [PATCH v9 11/11] qemu-iotests: test non-overlapping " Alberto Garcia
2016-04-27 13:50 ` Max Reitz
2016-04-08 10:00 ` [Qemu-devel] [PATCH for-2.7 v9 00/11] Support streaming to an intermediate layer Stefan Hajnoczi
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=5720B0FF.6070605@redhat.com \
--to=mreitz@redhat.com \
--cc=berto@igalia.com \
--cc=eblake@redhat.com \
--cc=kwolf@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.