qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, armbru@redhat.com
Subject: Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE
Date: Fri, 20 Dec 2019 11:26:56 +0100	[thread overview]
Message-ID: <20191220102656.GD4019@dhcp-200-226.str.redhat.com> (raw)
In-Reply-To: <20191219143818.1646168-3-mreitz@redhat.com>

Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
> fuse-export-add allows mounting block graph nodes via FUSE on some
> existing regular file.  That file should then appears like a raw disk
> image, and accesses to it result in accesses to the exported BDS.
> 
> Right now, we only set up the mount point and tear all mount points down
> in bdrv_close_all().  We do not implement any access functions, so
> accessing the mount point only results in errors.  This will be
> addressed by a followup patch.
> 
> The set of exported nodes is kept in a hash table so we can later add a
> fuse-export-remove that allows unmounting.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>

> diff --git a/qapi/block.json b/qapi/block.json
> index 145c268bb6..03f8d1b537 100644
> --- a/qapi/block.json
> +++ b/qapi/block.json
> @@ -317,6 +317,29 @@
>  ##
>  { 'command': 'nbd-server-stop' }
>  
> +##
> +# @fuse-export-add:
> +#
> +# Exports a block graph node on some (file) mountpoint as a raw image.
> +#
> +# @node-name: Node to be exported
> +#
> +# @mountpoint: Path on which to export the block device via FUSE.
> +#              This must point to an existing regular file.
> +#
> +# @writable: Whether clients should be able to write to the block
> +#            device via the FUSE export. (default: false)
> +#
> +# Since: 5.0
> +##
> +{ 'command': 'fuse-export-add',
> +  'data': {
> +      'node-name': 'str',
> +      'mountpoint': 'str',
> +      '*writable': 'bool'
> +  },
> +  'if': 'defined(CONFIG_FUSE)' }

Can this use a BlockExport union from the start like I'm introducing in
the storage daemon series, together with a generic block-export-add?

It also looks like node-name and writable should be part of the common
base of BlockExport. Unfortunately this would mean that I can't use the
same BlockExportNbd for the existing nbd-server-add command any more. I
guess I could somehow get a shared base type for both, though.

Markus, any thoughts on these QAPI interfaces?

Kevin



  reply	other threads:[~2019-12-20 10:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 14:38 [PATCH 00/18] block: Allow exporting BDSs via FUSE Max Reitz
2019-12-19 14:38 ` [PATCH 01/18] configure: Detect libfuse Max Reitz
2019-12-19 14:38 ` [PATCH 02/18] fuse: Allow exporting BDSs via FUSE Max Reitz
2019-12-20 10:26   ` Kevin Wolf [this message]
2019-12-20 10:48     ` Max Reitz
2019-12-20 11:24       ` Kevin Wolf
2019-12-20 12:09         ` Max Reitz
2019-12-20 12:48         ` Markus Armbruster
2019-12-20 12:58           ` Kevin Wolf
2019-12-20 13:25             ` Markus Armbruster
2019-12-20 21:18               ` Eric Blake
2019-12-20 12:49     ` Markus Armbruster
2019-12-20 13:02       ` Kevin Wolf
2019-12-20 21:15   ` Eric Blake
2020-01-06 12:00     ` Max Reitz
2019-12-19 14:38 ` [PATCH 03/18] fuse: Implement standard FUSE operations Max Reitz
2019-12-19 14:38 ` [PATCH 04/18] fuse: Add fuse-export-remove Max Reitz
2019-12-19 14:38 ` [PATCH 05/18] fuse: Allow growable exports Max Reitz
2019-12-19 14:38 ` [PATCH 06/18] fuse: (Partially) implement fallocate() Max Reitz
2019-12-19 14:38 ` [PATCH 07/18] fuse: Implement hole detection through lseek Max Reitz
2019-12-19 14:38 ` [PATCH 08/18] iotests: Do not needlessly filter _make_test_img Max Reitz
2019-12-19 14:38 ` [PATCH 09/18] iotests: Do not pipe _make_test_img Max Reitz
2019-12-19 14:38 ` [PATCH 10/18] iotests: Use convert -n in some cases Max Reitz
2019-12-19 14:38 ` [PATCH 11/18] iotests: Avoid renaming images Max Reitz
2019-12-19 14:38 ` [PATCH 12/18] iotests: Derive image names from $TEST_IMG Max Reitz
2019-12-19 14:38 ` [PATCH 13/18] iotests/091: Use _cleanup_qemu instad of "wait" Max Reitz
2019-12-19 14:38 ` [PATCH 14/18] iotests: Restrict some Python tests to file Max Reitz
2019-12-19 14:38 ` [PATCH 15/18] iotests: Let _make_test_img guess $TEST_IMG_FILE Max Reitz
2019-12-19 14:38 ` [PATCH 16/18] iotests: Allow testing FUSE exports Max Reitz
2019-12-19 14:38 ` [PATCH 17/18] iotests: Enable fuse for many tests Max Reitz
2019-12-19 14:38 ` [PATCH 18/18] iotests/281: Add test for FUSE exports Max Reitz
2019-12-19 19:05 ` [PATCH 00/18] block: Allow exporting BDSs via FUSE Max Reitz
2019-12-20 10:08 ` Stefan Hajnoczi
2019-12-20 10:30   ` Max Reitz
2019-12-20 12:50     ` Kevin Wolf
2019-12-20 21:20       ` Eric Blake
2020-01-02 11:22     ` 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=20191220102656.GD4019@dhcp-200-226.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@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).