On 04/28/2016 07:06 AM, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > >> Rather than having two separate ways to create a QMP input >> visitor, where the safer approach has the more verbose name, >> it is better to consolidate things into a single function >> where the caller must explicitly choose whether to be strict >> or to ignore excess input. Use strict mode in more places of >> internal code (such as when cloning a QAPI struct in >> util/socket.c, where the QObject better not have excess >> input since it was just generated by qmp-output), while >> documenting in user-facing code a question of whether we >> should change our policy about ignoring excess input. > > Which external interface is this?
QMP qom-set, via object_property_set_qobject()
>
>>
>> In the case of qmp_object_add(), we intentionally switch to a
>> strict visitor; this matches the fact that the code for
>> user_creatable_add_type() is shared by both qmp_object_add()
>> (QMP input visitor) and by user_creatable_add_opts() (QemuOpts
>> visitor); the latter is always strict, so our usage in the
>> former should also be strict, so that both visits will
>> equally diagnose any excess input in a nested dict. But in
>> practice, we don't really have any -object where the
>> properties are a nested dict, and excess input at the top
>> level is already caught earlier by object_property_set() on
>> an unknown key, whether from QemuOpts:
>>
>> $ ./x86_64-softmmu/qemu-system-x86_64 -nographic -nodefaults -qmp stdio
>> -object secret,id=sec0,data=letmein,format=raw,foo=bar
>> qemu-system-x86_64: Property '.foo' not found
>
> Let's update the error message now that the error message regression is
> fixed. Can do on commit.
>
Thanks. And now you know why I reported the regression.
>>
>> or from QMP:
>>
>> $ ./x86_64-softmmu/qemu-system-x86_64 -nographic -nodefaults -qmp stdio
>> {"QMP": {"version": {"qemu": {"micro": 93, "minor": 5, "major": 2},
>> "package": ""}, "capabilities": []}}
>> {"execute":"qmp_capabilities"}
>> {"return": {}}
>> {"execute":"object-add","arguments":{"qom-type":"secret","id":"sec0","props":{"format":"raw","data":"letmein","a":1}}}
>> {"error": {"class": "GenericError", "desc": "Property '.a' not found"}}
>>
>> Signed-off-by: Eric Blake <ebl...@redhat.com>
>
> Should we split this into a patch to change the interface, and one or
> more separate patches to switch to the strict visitor? Could result in
> clearer and more complete commit messages.
Could do.
>> +++ b/qom/qom-qobject.c
>> @@ -22,7 +22,8 @@ void object_property_set_qobject(Object *obj, QObject
>> *value,
>> const char *name, Error **errp)
>> {
>> QmpInputVisitor *qiv;
>> - qiv = qmp_input_visitor_new(value);
>> + /* TODO: Should we reject, rather than ignore, excess input? */
>> + qiv = qmp_input_visitor_new(value, false);
>> object_property_set(obj, qmp_input_get_visitor(qiv), name, errp);
>>
>> qmp_input_visitor_cleanup(qiv);
>
> Stay lenient, but document this should perhaps switch to strict. The
> commit message hints at this one.
"hints at" and "explicitly mentions by name" are two different things, I
get your point that my commit message could have been better.
>> +++ b/replay/replay-input.c
>> @@ -37,7 +37,7 @@ static InputEvent *qapi_clone_InputEvent(InputEvent *src)
>> return NULL;
>> }
>>
>> - qiv = qmp_input_visitor_new(obj);
>> + qiv = qmp_input_visitor_new(obj, true);
>> iv = qmp_input_get_visitor(qiv);
>> visit_type_InputEvent(iv, NULL, &dst, &error_abort);
>> qmp_input_visitor_cleanup(qiv);
>
> Switch to strict. Not mentioned in commit message. Why is it a good
> idea?
Same category as util/qemu-sockets.c: when cloning, we shouldn't be
introducing any junk from the QObject just produced from the qmp-output
visitor. (Hmm, that also means that when cloning, we are now doing MORE
work to check for a "can't happen" condition - but it all goes away in a
later patch when I introduce a real cloning visitor that is more
efficient than a round-trip qmp-output => qmp-input double pass - so
maybe on that grounds, I don't need to convert this or the
qemu-sockets.c case)
>> +++ b/tests/test-qmp-commands.c
>> @@ -222,7 +222,7 @@ static void test_dealloc_partial(void)
>> ud2_dict = qdict_new();
>> qdict_put_obj(ud2_dict, "string0", QOBJECT(qstring_from_str(text)));
>>
>> - qiv = qmp_input_visitor_new(QOBJECT(ud2_dict));
>> + qiv = qmp_input_visitor_new(QOBJECT(ud2_dict), true);
>> visit_type_UserDefTwo(qmp_input_get_visitor(qiv), NULL, &ud2, &err);
>> qmp_input_visitor_cleanup(qiv);
>> QDECREF(ud2_dict);
>
> Switch to strict. Not mentioned in commit message. Why is it a good
> idea?
Because it's a testsuite and still passes with stricter testing, thus
any future additions to the testsuite will exercise strict mode which is
what we want to use in more places.
>> +++ b/tests/test-qmp-input-visitor.c
>> @@ -51,7 +51,7 @@ static Visitor
>> *visitor_input_test_init_internal(TestInputVisitorData *data,
>> data->obj = qobject_from_jsonv(json_string, ap);
>> g_assert(data->obj);
>>
>> - data->qiv = qmp_input_visitor_new(data->obj);
>> + data->qiv = qmp_input_visitor_new(data->obj, false);
>> g_assert(data->qiv);
>>
>> v = qmp_input_get_visitor(data->qiv);
>> diff --git a/tests/test-visitor-serialization.c
>> b/tests/test-visitor-serialization.c
>
> Stay lenient (because we're testing it).
If we get rid of all lenient clients other than test-qmp-input-visitor,
then maybe lenient mode is worth nuking, and simplify our testsuite by
consolidating test-qmp-input-{visitor,strict}? But food for thought for
a later day.
>> +++ b/tests/test-visitor-serialization.c
>> @@ -1038,7 +1038,7 @@ static void qmp_deserialize(void **native_out, void
>> *datap,
>> obj = qobject_from_json(qstring_get_str(output_json));
>>
>> QDECREF(output_json);
>> - d->qiv = qmp_input_visitor_new(obj);
>> + d->qiv = qmp_input_visitor_new(obj, true);
>> qobject_decref(obj_orig);
>> qobject_decref(obj);
>> visit(qmp_input_get_visitor(d->qiv), native_out, errp);
>
> Switch to strict. Not mentioned in commit message. Why is it a good
> idea?
Same argument as test-qmp-commands, and same flaw in the commit message
for not calling it out.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
