On 05/18/2011 08:46 AM, Luiz Capitulino wrote:
On Tue, 17 May 2011 19:51:47 -0500
Michael Roth<mdr...@linux.vnet.ibm.com> wrote:
These apply on top of master, and can also be obtained from:
git://repo.or.cz/qemu/mdroth.git qapi_round1_v1
Nice to see this moving forward.
These patches are a backport of some of the QAPI-related work from Anthony's
glib tree. The main goal is to get the basic code generation infrastructure in
place so that it can be used by the guest agent to implement a QMP-like guest
interface, and so that future work regarding the QMP conversion to QAPI can be
decoupled from the infrastructure bits.
Round1 incorporates the following components from Anthony's tree:
- Pulls in GLib libraries (core GLib, GThreads, and GIO)
- Adds code to do exception-like error propagation
- New error reporting functions
- Schema-based code generation for QAPI types and synchronous QMP commands
using visiter patterns to cut reduce the amount of code generated by the
previous scripts. This is just infrastructure, QMP will remain untouched
until the actual conversion efforts are underway. Only a set of unit tests
and, in the guest, virtagent, will utilize this infrastructure initially.
This series introduces quite a lot of infrastructure w/o adding a single real
user. This has some disadvantages, the most important one being that we can't
test it for real (unit-tests are important, but don't replace real usage).
Another disadvantage is that, reviewers don't actually see how this is going to
be used and can't comment on API level improvements/bugs.
The guest agent user will mirror the QMP user pretty closely, but I
could see why it'd be nice to have an actual QMP user as part of the
series. I think we decided on IRC that an incremental QMP conversion
wouldn't be the best route and should instead be done as part of a
single concerted effort. So one approach I would propose is to have
example conversions tacked on to the end of this series.
So for this series we'd have 1 or 2 example conversions for synchronous
QMP functions. Future infrastructure patches could provide examples for
async QMP/proxied QMP/QMP event/qcfg/etc users as the relevant
infrastructure bits are added.
So long as the example conversions capture the general use cases, we'd
still be able to decouple conversion efforts from infrastructure (with
any corner cases fixed as a part of those efforts), while allowing the
infrastructure code to be reviewed in the proper context.
I prefer an incremental approach. We could try to split this series in smaller
parts and change current QMP to use that parts. This will make review easier
and will make it possible to do incremental testing too.
I could split the code conversion stuff out into a separate series. So
we'd have:
Round 1: error-related changes
Round 2: json-related changes
Round 3: code conversion infra + examples
If we take the approach mentioned above, anyway.
Otherwise I don't see how we could decouple any QMP conversion efforts
from infrastructure (which I think was considered desirable). In terms
of the code generation it's basically all or nothing, with the exception
of the unit tests we've added. Did you have something else in mind?
