Am 19.04.2018 um 17:25 hat Peter Krempa geschrieben:
'file' backend in qemu supports few more options than the current implementation. Extract it so that changes don't pollute the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- src/qemu/qemu_block.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c index c0cf6a95ad..e7bd6c909d 100644 --- a/src/qemu/qemu_block.c +++ b/src/qemu/qemu_block.c @@ -974,6 +974,18 @@ qemuBlockStorageSourceGetSshProps(virStorageSourcePtr src) }
+static virJSONValuePtr +qemuBlockStorageSourceGetFileProps(virStorageSourcePtr src) +{ + virJSONValuePtr ret = NULL; + + ignore_value(virJSONValueObjectCreate(&ret, + "s:driver", "file", + "s:filename", src->path, NULL) < 0); + return ret; +} + + /** * qemuBlockStorageSourceGetBackendProps: * @src: disk source @@ -991,9 +1003,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src) case VIR_STORAGE_TYPE_BLOCK: case VIR_STORAGE_TYPE_FILE: case VIR_STORAGE_TYPE_DIR: - if (virJSONValueObjectCreate(&fileprops, - "s:driver", "file", - "s:filename", src->path, NULL) < 0) + if (!(fileprops = qemuBlockStorageSourceGetFileProps(src))) return NULL;
Preexisting, but I wonder whether 'driver': 'file' is correct for all these cases. I see that you handle _DIR separately with a vvfat function later in this series, but shouldn't _BLOCK be 'host_device' rather than 'file', too? Kevin