From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqQvQ-0008Uh-Pl for qemu-devel@nongnu.org; Wed, 13 Apr 2016 15:58:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqQvL-0006Lg-El for qemu-devel@nongnu.org; Wed, 13 Apr 2016 15:58:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqQvL-0006Ka-7E for qemu-devel@nongnu.org; Wed, 13 Apr 2016 15:58:03 -0400 References: <1460131992-32278-1-git-send-email-eblake@redhat.com> <1460131992-32278-8-git-send-email-eblake@redhat.com> <87a8kxflyk.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: <570EA4C8.6060002@redhat.com> Date: Wed, 13 Apr 2016 13:58:00 -0600 MIME-Version: 1.0 In-Reply-To: <87a8kxflyk.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RgDrfQBI2CiBB4CEIAFGn2J9oqxQf3u9n" Subject: Re: [Qemu-devel] [PATCH v14 07/19] qmp-input: Refactor when list is advanced List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RgDrfQBI2CiBB4CEIAFGn2J9oqxQf3u9n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/13/2016 11:38 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> Refactor the code to advance the QListEntry pointer at the point >> where visit_type_FOO() is called, rather than visit_next_list(). >> This will allow a future patch to move the visit of the list head >> into visit_start_list(), and get rid of the 'first' flag. >> >> Signed-off-by: Eric Blake >=20 > After having read the patch, I think the change is from this sequence o= f > states >=20 > start_list next_list type_ELT ... next_list type_ELT end_lis= t > entry NULL 1st elt 1st elt last elt last elt gone >=20 > where type_ELT() returns (entry ? entry : 1st elt) and next_list() step= s > entry >=20 > to this one >=20 > start_list next_list type_ELT ... next_list type_ELT end_lis= t > entry 1st elt 1nd elt 2nd elt last elt NULL gone >=20 > where type_ELT() steps entry and returns the old entry, and next_list()= > leaves entry alone. Correct? Yes. I think I know what diagram I'll be adding to my commit message :) >=20 > Now have a look at the typical generated visit: Which gets greatly simplified later in 18/19 (ie. this patch is doing some of the refactoring to make 18/19 easier). >=20 > void visit_type_FOOList(Visitor *v, const char *name, FOOList **obj= , Error **errp) > { > Error *err =3D NULL; > FOOList *tail; > size_t size =3D sizeof(**obj); >=20 > visit_start_list(v, name, (GenericList **)obj, size, &err); > if (err) { > goto out; > } > for (tail =3D *obj; > tail; > tail =3D (FOOList *)visit_next_list(v, (GenericList *)tail= , size)) { > visit_type_FOO(v, NULL, &tail->value, &err); > if (err) { > break; > } > } > if (visit_end_list(v) && err) { > qapi_free_FOOList(*obj); > *obj =3D NULL; > } > out: > error_propagate(errp, err); > } >=20 > While the loop variable is still stepped in the for's third expression > as it should, the actual stepping below the hood now happens in the loo= p > body. I find this mildly confusing. There are TWO lists being stepped. The generated code is stepping through the GenericList *. The under-the-hood code is stepping through QList input. My refactoring here is to advance through the under-the-hood QList at the point where we CONSUME data (similar to how we remove things from QDict at the point where we CONSUME it) - during visit_type_FOO, and doesn't touch the GenericList* visits. Yes, that means the two are slightly out of sync, until 18/19 fixes the GenericList* visit to be sane (none of this magic visit the head of the list twice during visit_next_list). >=20 > Perhaps a more natural loop would be >=20 > void visit_type_FOOList(Visitor *v, const char *name, FOOList **obj= , Error **errp) > { > Error *err =3D NULL; > GenericList *tail; > size_t size =3D sizeof(**obj); >=20 > visit_start_list(v, name, (GenericList **)obj, size, &err); > if (err) { > goto out; > } > while ((tail =3D visit_next_list(v, tail, size))) { tail has to be set to something before this while loop will work. > visit_type_FOO(v, NULL, &((FOOList *)tail)->value, &err); > if (err) { > break; > } > } And that's kind of the whole point of 18/19. > if (visit_end_list(v) && err) { > qapi_free_FOOList(*obj); > *obj =3D NULL; > } > out: > error_propagate(errp, err); > } >=20 > Might also permit de-duplicating the g_malloc0(size), since we now call= > next_list() *before* each iteration instead of *between* iterations. One other wrinkle to think about in both this patch and 18/19: We have the annoying difference in representation that an empty GenericList* is the NULL pointer, while an empty QList is an actual object. >> @@ -77,7 +78,12 @@ static QObject *qmp_input_get_object(QmpInputVisito= r *qiv, > /* If we are in the middle of a list, then return the next eleme= nt >> * of the list. */ >> if (tos->entry) { >=20 > Before the patch, the condition matches the comment: tos->entry implies= > this is a list and we're not at its head. >=20 > After the patch, the condition only implies it's a list, but ... >=20 >> assert(qobject_type(qobj) =3D=3D QTYPE_QLIST); >> - return qlist_entry_obj(tos->entry); >> + assert(!tos->first); >=20 > ... you assert that "not at its head" can't happen. Why is that the > case? Because the only way to consume an element is by calling visit_type_FOO(), but until 18/19 reorders the generated loop, we don't call visit_type_FOO() until AFTER our first visit_next_list(). The only time "at its head" can happen is BEFORE the first visit_next_list(). >=20 >> + qobj =3D qlist_entry_obj(tos->entry); >> + if (consume) { >> + tos->entry =3D qlist_next(tos->entry); >> + } >> + return qobj; >=20 > The remainder of the hunk adds the qlist_next() call moved from > qmp_input_next_list(), as advertized by the commit message. Good. >=20 >> } >> >> /* Otherwise, we are at the root of the visit or the start of a >> @@ -91,7 +97,8 @@ static void qdict_add_key(const char *key, QObject *= obj, void *opaque) >> g_hash_table_insert(h, (gpointer) key, NULL); >> } >> >> -static void qmp_input_push(QmpInputVisitor *qiv, QObject *obj, Error = **errp) >> +static void qmp_input_push(QmpInputVisitor *qiv, QObject *obj, >> + const QListEntry *entry, Error **errp) >> { >> GHashTable *h; >> StackObject *tos =3D &qiv->stack[qiv->nb_stack]; >> @@ -103,7 +110,8 @@ static void qmp_input_push(QmpInputVisitor *qiv, Q= Object *obj, Error **errp) >> } >> >> tos->obj =3D obj; >> - tos->entry =3D NULL; >> + tos->entry =3D entry; >> + tos->first =3D true; >> tos->h =3D NULL; >> >> if (qiv->strict && qobject_type(obj) =3D=3D QTYPE_QDICT) { >=20 > Here, you change the initial state. Not explicitly advertized in the > commit message, unlike the change to qlist_next(). I guess that's okay= , > but perhaps my ramblings give you ideas on improving the commit message= =2E Sure. >=20 > I wonder whether we really need the new argument. Could we do somethin= g > like >=20 > if (qobject_type(obj) =3D=3D QTYPE_QLIST) { > tos->entry =3D qlist_first(qobject_to_qlist(obj)); > tos->first =3D true; > } >=20 I'll try it. But I seem to recall the reason I did it this way was because... > ? >=20 >> @@ -153,7 +161,7 @@ static void qmp_input_start_struct(Visitor *v, con= st char *name, void **obj, >> return; >> } >> >> - qmp_input_push(qiv, qobj, &err); >> + qmp_input_push(qiv, qobj, NULL, &err); >=20 > Since @qobj is a dictionary, the StackObject's entry will be unused, so= > pass null. Okay. >=20 >> if (err) { >> error_propagate(errp, err); >> return; >> @@ -175,6 +183,7 @@ static void qmp_input_start_list(Visitor *v, const= char *name, Error **errp) >> { >> QmpInputVisitor *qiv =3D to_qiv(v); >> QObject *qobj =3D qmp_input_get_object(qiv, name, true); >> + const QListEntry *entry; >> >> if (!qobj || qobject_type(qobj) !=3D QTYPE_QLIST) { >> error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "= null", >> @@ -182,7 +191,8 @@ static void qmp_input_start_list(Visitor *v, const= char *name, Error **errp) >> return; >> } >> >> - qmp_input_push(qiv, qobj, errp); >> + entry =3D qlist_first(qobject_to_qlist(qobj)); >> + qmp_input_push(qiv, qobj, entry, errp); >=20 > @qobj is a list, the StackObject's entry must be initialized to its > first member, so pass that. =2E..in 18/19, the semantics of visit_start_list() change such that we have to know whether we are visiting an empty QList (we set **obj differently for an empty vs. non-empty list) - so it was either grab entry locally and pass it in as a parameter, or let qmp_input_push() populate entry and then read it after the fact. >> @@ -382,7 +384,7 @@ QmpInputVisitor *qmp_input_visitor_new(QObject *ob= j) >> v->visitor.type_any =3D qmp_input_type_any; >> v->visitor.optional =3D qmp_input_optional; >> >> - qmp_input_push(v, obj, NULL); >> + qmp_input_push(v, obj, NULL, NULL); >=20 > @obj is the root of the visit. Can it be a list? >=20 > If yes, then StackObject's entry is not its first element. Why is that= > correct? Because when the root of the visit is a QList, you STILL have to call visit_start_list() before visiting list element members. It is visit_start_list() that sets up entry in preparation for visit_next_list(= ). The root of the QMP input visitor is currently a bit odd; we have weird semantics where a dictionary as root behaves differently depending on whether name is NULL or non-NULL. See 17/19, where I clean that up later in the series, at which point I get rid of the qmp_input_push() during visitor initialization. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RgDrfQBI2CiBB4CEIAFGn2J9oqxQf3u9n 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/ iQEcBAEBCAAGBQJXDqTIAAoJEKeha0olJ0NqoFcH/0/Lgo1AdZUKdFR9GlRmy4SD 9L3YOrZS2bDUMe9X6MwK2EEWfz9Yh3KzBNied9rbq6sXdEhZW992onTn82yyCNyg lf9vsUi/JJf7XdkoG8peeVrl0Ydth67EgPNXjWcIy4KOMX75XDOl0+241iztzCfd l4GuhStxR7deOiE4qoxjqxkGQKECloO+L8KX1ykEyqd/nLkHGJwU0HSGUkq95QY2 Y8BVU7XeIN5Yt8iccUah4yE3DEl7keWJ9H6BSJmeSXlfF1exO7yv3Cuz4sMOnkpE YtCCKz8S1/TAwyMTy6wh3jTdlTkgEpxY7dxI4GMiDwuJKRif8TpLlk0geZPL7w0= =aS2M -----END PGP SIGNATURE----- --RgDrfQBI2CiBB4CEIAFGn2J9oqxQf3u9n--