From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [RFC PATCH 04/22] block/export: Add BlockExport infrastructure and block-export-add
Date: Mon, 17 Aug 2020 14:45:44 +0200 [thread overview]
Message-ID: <20200817124544.GI11402@linux.fritz.box> (raw)
In-Reply-To: <7ed669db-7a75-fb25-4ce6-52369ea01b4b@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4636 bytes --]
Am 17.08.2020 um 12:03 hat Max Reitz geschrieben:
> On 13.08.20 18:29, Kevin Wolf wrote:
> > We want to have a common set of commands for all types of block exports.
> > Currently, this is only NBD, but we're going to add more types.
> >
> > This patch adds the basic BlockExport and BlockExportDriver structs and
> > a QMP command block-export-add that creates a new export based on the
> > given BlockExportOptions.
> >
> > qmp_nbd_server_add() becomes a wrapper around qmp_block_export_add().
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > qapi/block-export.json | 9 ++++++
> > include/block/export.h | 32 +++++++++++++++++++++
> > include/block/nbd.h | 3 +-
> > block/export/export.c | 57 ++++++++++++++++++++++++++++++++++++++
> > blockdev-nbd.c | 19 ++++++++-----
> > nbd/server.c | 15 +++++++++-
> > Makefile.objs | 6 ++--
> > block/Makefile.objs | 2 ++
> > block/export/Makefile.objs | 1 +
> > 9 files changed, 132 insertions(+), 12 deletions(-)
> > create mode 100644 include/block/export.h
> > create mode 100644 block/export/export.c
> > create mode 100644 block/export/Makefile.objs
>
> Nothing of too great importance below. But it’s an RFC, so comments I
> will give.
>
> > diff --git a/block/export/export.c b/block/export/export.c
> > new file mode 100644
> > index 0000000000..3d0dacb3f2
> > --- /dev/null
> > +++ b/block/export/export.c
> > @@ -0,0 +1,57 @@
> > +/*
> > + * Common block export infrastructure
> > + *
> > + * Copyright (c) 2012, 2020 Red Hat, Inc.
> > + *
> > + * Authors:
> > + * Paolo Bonzini <pbonzini@redhat.com>
> > + * Kevin Wolf <kwolf@redhat.com>
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > + * later. See the COPYING file in the top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +
> > +#include "block/export.h"
> > +#include "block/nbd.h"
> > +#include "qapi/error.h"
> > +#include "qapi/qapi-commands-block-export.h"
> > +
> > +static const BlockExportDriver* blk_exp_drivers[] = {
> ^^
> Sternenplatzierung *hust*
>
> > + &blk_exp_nbd,
> > +};
>
> Not sure whether I like this better than the block driver way of
> registering block drivers with a constructor. It requires writing less
> code, at the expense of making the variable global. So I think there’s
> no good reason to prefer the block driver approach.
I guess I can see one reason why we may want to switch to the
registration style eventually: If we we want to make export drivers
optional modules which may or may not be present.
> Maybe my hesitance comes from the variable being declared (as extern) in
> a header file (block/export.h). I think I would prefer it if we put
> that external reference only here in this file. Would that work, or do
> you have other plans that require blk_exp_nbd to be visible outside of
> nbd/server.c and this file here?
Hm, do we have precedence for "public, but not really" variables?
Normally I expect public symbols to be declared in a header file.
> > +static const BlockExportDriver *blk_exp_find_driver(BlockExportType type)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(blk_exp_drivers); i++) {
> > + if (blk_exp_drivers[i]->type == type) {
> > + return blk_exp_drivers[i];
> > + }
> > + }
>
> How bad would it be to define blk_exp_drivers as
> blk_exp_drivers[BLOCK_EXPORT_TYPE__MAX] and use the BlockExportType as
> the driver index so we don’t have to loop here?
>
> Not that it matters performance-wise. Just something I wondered.
Might be nicer indeed. It would be incompatible with a registration
model, though, so if we're not sure yet what we want to have in the long
term, maybe the more neutral way is to leave it as it is.
> > + return NULL;
>
> Why not e.g. g_assert_not_reached()?
>
> (If the BlockExportType were used as the index, I’d assert that
> type < ARRAY_SIZE(blk_exp_drivers) && blk_exp_drivers[type] != NULL. I
> don’t think there’s a reason for graceful handling.)
Same thing actually. This works as long as all drivers are always
present.
Now I understand that the current state is somewhat inconsistent in that
it uses a simple array of things that are always present, but has
functions that work as if it were dynamic. I don't mind this
inconsistency very much, but if you do, I guess I could implement a
registration type thing right away.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-17 12:47 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 16:29 [RFC PATCH 00/22] block/export: Add infrastructure and QAPI for block exports Kevin Wolf
2020-08-13 16:29 ` [RFC PATCH 01/22] nbd: Remove unused nbd_export_get_blockdev() Kevin Wolf
2020-08-17 8:14 ` Max Reitz
2020-08-19 18:13 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 02/22] qapi: Create block-export module Kevin Wolf
2020-08-17 8:50 ` Max Reitz
2020-08-19 18:17 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 03/22] qapi: Rename BlockExport to BlockExportOptions Kevin Wolf
2020-08-17 9:13 ` Max Reitz
2020-08-19 18:19 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 04/22] block/export: Add BlockExport infrastructure and block-export-add Kevin Wolf
2020-08-17 10:03 ` Max Reitz
2020-08-17 12:45 ` Kevin Wolf [this message]
2020-08-17 13:19 ` Max Reitz
2020-08-17 13:29 ` Kevin Wolf
2020-08-17 13:53 ` Max Reitz
2020-08-19 18:31 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 05/22] qemu-storage-daemon: Use qmp_block_export_add() Kevin Wolf
2020-08-17 10:13 ` Max Reitz
2020-08-19 19:14 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 06/22] qemu-nbd: Use raw block driver for --offset Kevin Wolf
2020-08-17 10:56 ` Max Reitz
2020-08-17 11:41 ` Max Reitz
2020-08-17 17:19 ` Nir Soffer
2020-08-18 8:47 ` Kevin Wolf
2020-08-18 9:05 ` Nir Soffer
2020-08-19 19:33 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 07/22] block/export: Remove magic from block-export-add Kevin Wolf
2020-08-17 11:41 ` Max Reitz
2020-08-17 12:49 ` Kevin Wolf
2020-08-17 13:22 ` Max Reitz
2020-08-19 19:50 ` Eric Blake
2020-08-20 11:05 ` Kevin Wolf
2020-08-20 14:41 ` Eric Blake
2020-08-20 15:28 ` Peter Krempa
2020-08-13 16:29 ` [RFC PATCH 08/22] nbd: Add max-connections to nbd-server-start Kevin Wolf
2020-08-17 12:37 ` Max Reitz
2020-08-17 13:01 ` Kevin Wolf
2020-08-19 20:00 ` Eric Blake
2020-08-20 11:12 ` Kevin Wolf
2020-08-13 16:29 ` [RFC PATCH 09/22] nbd: Add writethrough to block-export-add Kevin Wolf
2020-08-17 12:56 ` Max Reitz
2020-08-17 13:13 ` Kevin Wolf
2020-08-17 13:51 ` Max Reitz
2020-08-17 14:32 ` Kevin Wolf
2020-08-17 15:35 ` Max Reitz
2020-08-19 20:05 ` Eric Blake
2020-08-19 20:13 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 10/22] nbd: Remove NBDExport.close callback Kevin Wolf
2020-08-17 14:02 ` Max Reitz
2020-08-19 20:17 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 11/22] qemu-nbd: Use blk_exp_add() to create the export Kevin Wolf
2020-08-17 14:27 ` Max Reitz
2020-08-17 14:38 ` Max Reitz
2020-08-17 15:01 ` Kevin Wolf
2020-08-19 20:35 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 12/22] nbd/server: Simplify export shutdown Kevin Wolf
2020-08-17 14:32 ` Max Reitz
2020-08-19 20:45 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 13/22] block/export: Move refcount from NBDExport to BlockExport Kevin Wolf
2020-08-17 14:49 ` Max Reitz
2020-08-19 20:58 ` Eric Blake
2020-08-20 14:15 ` Kevin Wolf
2020-08-13 16:29 ` [RFC PATCH 14/22] block/export: Move AioContext " Kevin Wolf
2020-08-17 14:56 ` Max Reitz
2020-08-17 15:22 ` Kevin Wolf
2020-08-17 15:47 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 15/22] block/export: Move device to BlockExportOptions Kevin Wolf
2020-08-17 15:13 ` Max Reitz
2020-08-17 15:27 ` Kevin Wolf
2020-08-17 15:49 ` Max Reitz
2020-08-19 21:13 ` Eric Blake
2020-08-13 16:29 ` [RFC PATCH 16/22] block/export: Allocate BlockExport in blk_exp_add() Kevin Wolf
2020-08-18 14:25 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 17/22] block/export: Add blk_exp_close_all(_type) Kevin Wolf
2020-08-18 15:00 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 18/22] block/export: Add 'id' option to block-export-add Kevin Wolf
2020-08-18 15:08 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 19/22] block/export: Move strong user reference to block_exports Kevin Wolf
2020-08-19 8:35 ` Max Reitz
2020-08-19 11:56 ` Max Reitz
2020-08-19 14:23 ` Kevin Wolf
2020-08-19 14:48 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 20/22] block/export: Add block-export-del Kevin Wolf
2020-08-19 9:54 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 21/22] block/export: Move blk to BlockExport Kevin Wolf
2020-08-19 10:53 ` Max Reitz
2020-08-13 16:29 ` [RFC PATCH 22/22] block/export: Add query-block-exports Kevin Wolf
2020-08-19 11:04 ` Max Reitz
2020-08-19 12:04 ` Kevin Wolf
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=20200817124544.GI11402@linux.fritz.box \
--to=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 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).