Am 22.11.2013 um 17:10 hat Max Reitz geschrieben:
> If the filename is not prefixed by "blkverify:" in
> blkverify_parse_filename(), the blkverify driver was not selected
> through that protocol prefix, but by an explicit command line option
> (like file.driver=blkverify). Contrary to the current reaction, this is
> not really a problem; the whole filename just has to be stored (in the
> x-image option) and the user has to manually specify the x-raw option.
>
> Signed-off-by: Max Reitz <mre...@redhat.com>
> ---
> block/blkverify.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/block/blkverify.c b/block/blkverify.c
> index 3c63528..bdbdd68 100644
> --- a/block/blkverify.c
> +++ b/block/blkverify.c
> @@ -78,7 +78,9 @@ static void blkverify_parse_filename(const char *filename,
> QDict *options,
>
> /* Parse the blkverify: prefix */
> if (!strstart(filename, "blkverify:", &filename)) {
> - error_setg(errp, "File name string must start with 'blkverify:'");
> + /* There was no prefix; therefore, all options have to be already
> + present in the QDict (except for the filename) */
> + qdict_put(options, "x-image", qstring_from_str(filename));
> return;
> }
We don't want users to specify x-raw options, that's why it starts with
"x-" in the first place. So I'm not sure if this patch is a useful
intermediate step to make.
What we want to allow in the end is something like this:
{ "execute": "blockdev-add", "options": {
{ "driver": "blkverify",
"image": {
"driver": "qcow2",
"file": ... },
"raw:" {
"driver": "raw",
"file": ... } } }
Where "image" and "raw" are both of the BlockdevRef union type in QAPI,
i.e. there could also be a string that references an existing block
device.
We'll probably want a function that takes a BlockdevRef and returns a
BlockDriverState; either by bdrv_open() on a new one, or by bdrv_ref()
on an existing one.
Fam already has some code to achieve this in his BlockOp blockers
series, though not yet in a reusable way. I guess this series is the
good reason to actually request something reusable and then make use of
it here.
I guess you two just need to coordinate who's going to implement it (Fam
by default, I'd assume?)
Kevin
