Kevin Wolf <kw...@redhat.com> writes: > Am 20.12.2019 um 11:48 hat Max Reitz geschrieben: >> On 20.12.19 11:26, Kevin Wolf wrote: >> > 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? >> >> Hm, you mean still adding a FuseExport structure that would be part of >> BlockExport and then dropping fuse-export-add in favor of a >> block-export-add that we want anyway? > > Yes. > >> > It also looks like node-name and writable should be part of the common >> > base of BlockExport. >> >> node-name definitely, I’m not so sure about writable. Or, to be more >> precise, I think that if we want writable to be in the base, we also >> want growable to be there: Both are primarily options for the >> BlockBackend that the exports use. >> >> But both of course also need to be supported by the export >> implementation. nbd can make its BB growable all it wants, but that >> doesn’t make it work. > > Right. Pragmatically, I think exports are very like to support writable, > but probably rather unlikely to support growable. So I do think there > would be a point for making writable part of the common base, but not > growable. > >> So if we kept writable and growable in the common base, then the schema >> would give no information about what exports actually support them. >> >> On one hand, I don’t know whether it’s important to have this >> information in a static form, or whether it’s sufficient to learn at >> runtime. >> >> On the other, I don’t know whether it’s important to have those fields >> in the base or not. Would it make a difference on the wire? > > Not for the command itself, so I think we're free to change it later. It > might make a difference for introspection, though, not sure. Markus?
QAPI schema introspection is designed to hide the difference between local members and base members. You can move members to or from a base type freely without affecting introspection. Even if that creates or deletes the base type. Example: DriveBackup { 'struct': 'DriveBackup', 'base': 'BackupCommon', 'data': { 'target': 'str', '*format': 'str', '*mode': 'NewImageMode' } } where BackupCommon is { 'struct': 'BackupCommon', 'data': { '*job-id': 'str', 'device': 'str', 'sync': 'MirrorSyncMode', '*speed': 'int', '*bitmap': 'str', '*bitmap-mode': 'BitmapSyncMode', '*compress': 'bool', '*on-source-error': 'BlockdevOnError', '*on-target-error': 'BlockdevOnError', '*auto-finalize': 'bool', '*auto-dismiss': 'bool', '*filter-node-name': 'str' } } query-qmp-schema describes DriveBackup like this: {"name": "30", "members": [ {"name": "job-id", "default": null, "type": "str"}, {"name": "device", "type": "str"}, {"name": "sync", "type": "235"}, {"name": "speed", "default": null, "type": "int"}, {"name": "bitmap", "default": null, "type": "str"}, {"name": "bitmap-mode", "default": null, "type": "236"}, {"name": "compress", "default": null, "type": "bool"}, {"name": "on-source-error", "default": null, "type": "237"}, {"name": "on-target-error", "default": null, "type": "237"}, {"name": "auto-finalize", "default": null, "type": "bool"}, {"name": "auto-dismiss", "default": null, "type": "bool"}, {"name": "filter-node-name", "default": null, "type": "str"}, {"name": "target", "type": "str"}, {"name": "format", "default": null, "type": "str"}, {"name": "mode", "default": null, "type": "234"}], "meta-type": "object"} [...]