Am 20.12.2019 um 13:49 hat Markus Armbruster geschrieben: > Kevin Wolf <kw...@redhat.com> writes: > > > 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 <mre...@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? > > Context? How far back should I read?
Basically just the hunk quoted above and the QAPI portion of the following storage daemon patch: [RFC PATCH 08/18] qemu-storage-daemon: Add --export option Maybe the cover letter, too, if you need a more high-level introduction. Kevin