From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6EDn-0001Kc-1Z for qemu-devel@nongnu.org; Tue, 08 Dec 2015 04:06:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6EDg-0006wY-T6 for qemu-devel@nongnu.org; Tue, 08 Dec 2015 04:06:06 -0500 Date: Tue, 8 Dec 2015 15:51:54 +1100 From: David Gibson Message-ID: <20151208045154.GO20139@voom.fritz.box> References: <1449546921-6378-1-git-send-email-eblake@redhat.com> <1449546921-6378-30-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QRo3kt64Wi40AlcO" Content-Disposition: inline In-Reply-To: <1449546921-6378-30-git-send-email-eblake@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 29/31] qapi: Simplify semantics of visit_next_list() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Michael Roth , Alexander Graf , "open list:sPAPR (pseries)" , qemu-devel@nongnu.org, armbru@redhat.com --QRo3kt64Wi40AlcO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2015 at 08:55:19PM -0700, Eric Blake wrote: > We have two uses of list visits in the entire code base: one in > spapr_drc (which completely avoids visit_next_list(), feeding in > integers from a different source than uint8List), and one in > qapi-visit.py (that is, all other list visitors are generated > in qapi-visit.c, and share the same paradigm based on a qapi > FooList type). What's more, the semantics of the list visit are > somewhat baroque, with the following pseudocode when FooList is > used: >=20 > start() > prev =3D head > while (cur =3D next(prev)) { > visit(cur) > prev =3D &cur > } >=20 > Note that these semantics (advance before visit) requires that > the first call to next() return the list head, while all other > calls return the next element of the list; that is, every visitor > implementation is required to track extra state to decide whether > to return the input as-is, or to advance. It also requires an > argument of 'GenericList **' to next(), solely because the first > iteration might need to modify the caller's GenericList head, so > that all other calls have to do a layer of dereferencing. >=20 > We can greatly simplify things by hoisting the special case > into the start() routine, and flipping the order in the loop > to visit before advance: >=20 > start(head) > element =3D *head > while (element) { > visit(element) > element =3D next(element) > } >=20 > With the simpler semantics, visitors have less state to track, > the argument to next() is reduced to 'GenericList *', and it > also becomes obvious whether an input visitor is allocating a > FooList during visit_start_list() (rather than the old way of > not knowing if an allocation happened until the first > visit_next_list()). >=20 > The spapr_drc case requires that visit_start_list() has to pay > attention to whether visit_next_list() will even be used to > visit a FooList qapi struct; this is done by passing NULL for > list, similarly to how NULL is passed to visit_start_struct() > when a qapi type is not used in those visits. It was easy to > provide these semantics for qmp-output and dealloc visitors, > and a bit harder for qmp-input (it required hoisting the > advance of the current qlist entry out of qmp_input_next_list() > into qmp_input_get_object()). But it turned out that the > string and opts visitors munge enough state during > visit_next_list() to make those conversions simpler if they > require a GenericList visit for now; an assertion will remind > us to adjust things if we need the semantics in the future. >=20 > Signed-off-by: Eric Blake For the spapr change: Acked-by: David Gibson --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --QRo3kt64Wi40AlcO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWZmHpAAoJEGw4ysog2bOSiJ8P/Ag/1eQcDMbnlQd6rQayG/WW HnWTc8XNQx5lGU0ASLAk69ZqsaMwt1b13IHa3qC1P7vsZGlo5cd7DJcXGKfBCWEA xc6cz/WEAp9JYEXjeVfDpmGphexXWbBq9tc4Rzw2ygSl8a0uY9UIzXyp9RWb3h+Y a77Il+76TN1VMTwXBLdLr74Y63a6qZh/ns45OYEe1bk/tEWhfOTB2M5Rrh55CnXz OO3SbroxgXpUo8Wn1+VAdeCfXVOJeLhmmrahVEpNqkBnGy9eC2cpESLiC6LSTNyy E9QcAHc3KmM7bQiHRDQ9fU3yfefqpNhMfk8WYThMabU/n815olP7At5pfiD8S+MZ Vq4/9zFYr7WZpaQGxiYdlcCQo6D5Ga/CNNbreMnUYR3F10psB3Glvzf67XuQW8af 2QAWC4m69vXCJ5Ot7UcyTLNAUuYFtN1Wk4F+TdG4BQE3F7nszeDVWzSBrGn0xVfW yYMnrz9A3AcFSiZ5qLqIITasXvRJyqEhZT4xIY7QcT0b5dYKRs47lYjRuOZD/pDz QdOuyie2GaVn8o0rm4Wfh10S/PYY+JOxddXb19NZFYfJb9OKrPsQKiX18bByf4EU NrDGTy58Pql2Gr6Zle910GgsT/PTOJHc7/3ZThrygP6bjOi/CZDF7gb3iHzILYDX pWoBxlHF8JhX27syVoKi =Haxr -----END PGP SIGNATURE----- --QRo3kt64Wi40AlcO--