[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 00/28] drop qapi nested structs

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v5 00/28] drop qapi nested structs
Date: Fri, 27 Mar 2015 13:50:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eric Blake <address@hidden> writes:

> After several months of sitting on this, I finally made progress
> on it.  Let's get it in 2.4, and I promise to kick out a v6
> (if needed) with much less delay.
> We want to eventually allow qapi defaults, by making:
>  'data':{'*flag':'bool'}
> shorthand for:
>  'data':{'flag':{'type':'bool', 'optional':true}}
> so that the default can be specified:
>  'data':{'flag':{'type':'bool', 'optional':true, 'default':true}}
> This series does not quite get us there, but it DOES do a number
> of other things.  It gets rid of the three uses of nested inline
> structs, changes anonymous unions to use a specific 'alternate'
> metatype rather than abusing 'union', and fixes lots of other
> parser bugs found while designing the testsuite.  The testsuite
> changes make the bulk of this series, with a repeating pattern
> of writing tests that expose weaknesses in the old parser, then
> beefing up the generator to catch the problem during the initial
> parse rather than choking with an obscure python message or even
> causing a C compilation failure.
> v4 was here:
> https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg04022.html
> Changes since then: lots of refactoring; 8 new commits; lots of
> testsuite additions; address Markus' review comments where I
> could.  However, so much has changed, and so much time elapsed,
> that it is probably easier to just review this series fresh than
> to try and compare it to earlier versions.

Okay, I'm through.  I like it well, and I think it's really close.
There are a few questions / ideas you haven't replied to already in
PATCH 21ff.  With those conversations wrapped up, I may well agree to
taking the series as is, but I think I'd prefer a *conservative* respin
addressing stuff that doesn't need new testing, like commit messages and
comments, and *selected* (by you) improvments that do need new testing.

reply via email to

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