qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for rtc
Date: Tue, 5 Jun 2012 11:03:18 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jun 05, 2012 at 11:29:24AM +0200, Kevin Wolf wrote:
> Am 05.06.2012 03:00, schrieb Michael Roth:
> > Signed-off-by: Michael Roth <address@hidden>
> > ---
> >  qidl-generated/mc146818rtc.json |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >  create mode 100644 qidl-generated/mc146818rtc.json
> 
> I haven't looked at the Makefiles, but does this commit mean that the
> files aren't generated automatically but you have to run the generator
> manually after changing any device struct?

Nope, the files are automatically generated when changes are made to
QIDL sources and you do a build.

The reason they're still checked-in is so that changes to a device's
serialization schema can be "signed-off" by the author that made the
change. This applies to qidl-generated vmstate descriptions as well.

It also makes an automated `make check-qidl` and, in the case of
qidl-generated vmstate descriptions, `make check-vmstate` possible, so
that a submitter/maintainer can detect and bring attention to changes to
serialized device state that need to be addressed/signed-off when
testing/reviewing patches.

We could get part of the way there by just keeping tabs on changes to qidl
sources, but ultimately how we do the serialization is a matter of how the
generated visitors look, in which case the generated QAPI schemas are the more
reliable representation. Annotations are hints, schemas are ABI, so
tracking the latter is more important.

Similar rationale for vmstate: the relationship between annotations and
the generated vmstate descriptions isn't strong enough that we can
easily infer changes based on qidl annotations, and in many cases those
inferred changes will be overwritten by special handling in the vmstate
generator.

It is ugly though... and I'm certainly open to alternative approaches.

> 
> Kevin
> 



reply via email to

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