From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avmvQ-0001fC-P0 for qemu-devel@nongnu.org; Thu, 28 Apr 2016 10:28:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1avmvL-0000hV-Nu for qemu-devel@nongnu.org; Thu, 28 Apr 2016 10:28:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avmvL-0000hQ-G5 for qemu-devel@nongnu.org; Thu, 28 Apr 2016 10:28:11 -0400 References: <1461801715-24307-1-git-send-email-eblake@redhat.com> <1461801715-24307-6-git-send-email-eblake@redhat.com> <871t5popb4.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: <57221DF9.1010201@redhat.com> Date: Thu, 28 Apr 2016 08:28:09 -0600 MIME-Version: 1.0 In-Reply-To: <871t5popb4.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LItx4mO2W94XxTCB3tD69TKcwjHpGtJ01" Subject: Re: [Qemu-devel] [PATCH v15 05/23] qapi: Use strict QMP input visitor in more places List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth , Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Andreas_F=c3=a4rber?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LItx4mO2W94XxTCB3tD69TKcwjHpGtJ01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/28/2016 07:06 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> 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. >=20 > Which external interface is this? QMP qom-set, via object_property_set_qobject() >=20 >> >> 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 stdi= o -object secret,id=3Dsec0,data=3Dletmein,format=3Draw,foo=3Dbar >> qemu-system-x86_64: Property '.foo' not found >=20 > Let's update the error message now that the error message regression is= > fixed. Can do on commit. >=20 Thanks. And now you know why I reported the regression. >> >> or from QMP: >> >> $ ./x86_64-softmmu/qemu-system-x86_64 -nographic -nodefaults -qmp stdi= o >> {"QMP": {"version": {"qemu": {"micro": 93, "minor": 5, "major": 2}, "p= ackage": ""}, "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 >=20 > 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, QObjec= t *value, >> const char *name, Error **errp) >> { >> QmpInputVisitor *qiv; >> - qiv =3D qmp_input_visitor_new(value); >> + /* TODO: Should we reject, rather than ignore, excess input? */ >> + qiv =3D qmp_input_visitor_new(value, false); >> object_property_set(obj, qmp_input_get_visitor(qiv), name, errp);= >> >> qmp_input_visitor_cleanup(qiv); >=20 > 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 =3D qmp_input_visitor_new(obj); >> + qiv =3D qmp_input_visitor_new(obj, true); >> iv =3D qmp_input_get_visitor(qiv); >> visit_type_InputEvent(iv, NULL, &dst, &error_abort); >> qmp_input_visitor_cleanup(qiv); >=20 > 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 =3D> 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 =3D qdict_new(); >> qdict_put_obj(ud2_dict, "string0", QOBJECT(qstring_from_str(t= ext))); >> >> - qiv =3D qmp_input_visitor_new(QOBJECT(ud2_dict)); >> + qiv =3D 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); >=20 > 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(Tes= tInputVisitorData *data, >> data->obj =3D qobject_from_jsonv(json_string, ap); >> g_assert(data->obj); >> >> - data->qiv =3D qmp_input_visitor_new(data->obj); >> + data->qiv =3D qmp_input_visitor_new(data->obj, false); >> g_assert(data->qiv); >> >> v =3D qmp_input_get_visitor(data->qiv); >> diff --git a/tests/test-visitor-serialization.c b/tests/test-visitor-s= erialization.c >=20 > 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, v= oid *datap, >> obj =3D qobject_from_json(qstring_get_str(output_json)); >> >> QDECREF(output_json); >> - d->qiv =3D qmp_input_visitor_new(obj); >> + d->qiv =3D qmp_input_visitor_new(obj, true); >> qobject_decref(obj_orig); >> qobject_decref(obj); >> visit(qmp_input_get_visitor(d->qiv), native_out, errp); >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --LItx4mO2W94XxTCB3tD69TKcwjHpGtJ01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXIh35AAoJEKeha0olJ0Nq8KoH/0FhvF6lTiNC61YHkNa8RbLI TRQNwwpKE6HobfJFgHcLrywlk+eNhznOaNZz6FXXwuE1ybAO5Uf8iNYiLHMZVJ4r Nm9oMtD6X45w5CY2f/nRY3t41+tFJBCcVbwagEIVJMk6NcK+dfoNvUvibQxsagAT 4Mh+XqGHKHC+eKnOBKP9UEf4aDDOwd3KkwZxiMnUsyNHEv+DGrWRjNqACZYcjtpZ MZUiAhozoidGbMnJ8btp7E80hWEFa/VQWcJH+N/XwEfaxTCVh/4WzGz8WBO4Ntyp sFJm6BvQ0P8jbjqixe13vxbXax0IJiTO8o2enj8LbsU3hj10rfYgQyJ+tLESZdM= =89Du -----END PGP SIGNATURE----- --LItx4mO2W94XxTCB3tD69TKcwjHpGtJ01--