qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v3 5/5] block: Crude initial implementation


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC v3 5/5] block: Crude initial implementation of -blockdev
Date: Thu, 23 Feb 2017 10:48:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 02/21/2017 03:01 PM, Markus Armbruster wrote:
>> The new command line option -blockdev works like QMP command
>> blockdev-add.
>> 
>> The option argument may be given in JSON syntax, exactly as in QMP.
>> Example usage:
>> 
>>     -blockdev '{"node-name": "foo", "driver": "raw", "file": {"driver": 
>> "file", "filename": "foo.img"} }'
>> 
>> The JSON argument doesn't exactly blend into the existing option
>> syntax, so the traditional KEY=VALUE,... syntax is also supported,
>> using dotted keys to do the nesting:
>> 
>>     -blockdev node-name=foo,driver=raw,file.driver=file,file.filename=foo.img
>
> Some of the list ideas were allowing mix-and-match or re-opening the
> dict; do we want to allow any of these? (maybe as followups?)
>
> -blockdev
> node-name=foo,driver=raw,file='{"driver":"file"}',file.filename=foo.img

No.  The initial version needs to be as simple as I can make it to give
me a chance at making 2.9.

Also, coming right from QemuOpts work, I'm in no mood for sugar.

>> Note that calling qmp_blockdev_add() (say via qmp_marshal_block_add())
>> right away would crash.  We need to stash the configuration for later
>> instead.  This is crudely done, and bypasses QemuOpts, even though
>> storing configuration is what QemuOpts is for.  Need to revamp option
>> infrastructure to support QAPI types like BlockdevOptions.
>> 
>> Signed-off-by: Markus Armbruster <address@hidden>
>> ---
>>  qemu-options.hx |  3 +++
>>  vl.c            | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 53 insertions(+)
>> 
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 9936cf3..36a38d7 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -512,6 +512,9 @@ Use @var{file} as CD-ROM image (you cannot use 
>> @option{-hdc} and
>>  using @file{/dev/cdrom} as filename (@pxref{host_drives}).
>>  ETEXI
>>  
>> +DEF("blockdev", HAS_ARG, QEMU_OPTION_blockdev,
>> +    "-blockdev FIXME document\n", QEMU_OPTION_blockdev)
>
> Adequate for an RFC, but I can see how you want to improve it.

:)

>> @@ -3095,6 +3104,37 @@ int main(int argc, char **argv, char **envp)
>>                  drive_add(IF_DEFAULT, popt->index - QEMU_OPTION_hda, optarg,
>>                            HD_OPTS);
>>                  break;
>> +            case QEMU_OPTION_blockdev:
>> +                {
>> +                    BlockdevOptions_queue *bdo = 
>> g_new(BlockdevOptions_queue, 1);
>> +                    bool is_json = optarg[0] == '{';
>> +                    QObject *obj;
>> +                    QDict *args;
>> +                    Visitor *v;
>> +
>> +                    if (is_json) {
>> +                        obj = qobject_from_json(optarg);
>> +                        // TODO get error out of parser
>
> Yeah, that's something we still need to improve.

Elsewhere, too:

    req = json_parser_parse_err(tokens, NULL, &err);
    if (err || !req || qobject_type(req) != QTYPE_QDICT) {
        if (!err) {
            error_setg(&err, QERR_JSON_PARSING);
        }
        goto err_out;
    }

>> +                        if (!obj) {
>> +                            error_report("invalid JSON");
>> +                            exit(1);
>> +                        }
>> +                        args = qobject_to_qdict(obj);
>> +                        assert(args);
>> +                        v = qobject_input_visitor_new(QOBJECT(args), true);
>> +                    } else {
>> +                        args = keyval_parse(optarg, "driver", &error_fatal);
>> +                        v = 
>> qobject_input_visitor_new_autocast(QOBJECT(args));
>> +                    }
>
> Pretty slick!  And answers my question: no mix-and-match of JSON and
> dotted (all one or the other) within a single -blockdev argument.

Thanks!  I think you can see where I'm trying to head: towards a
QAPIfied command line.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]