[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
Re: [Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for rtc
Wed, 06 Jun 2012 09:38:24 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
Am 05.06.2012 18:03, schrieb Michael Roth:
> 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.
Doesn't really make sense to me. You already have a sign-off for the
changed header/source file.
> 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.
Why can't 'make check-qidl' generate the new version itself like a
simple 'make' would do?
> 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.
So your statement is that the generator is likely buggy and therefore
its output should be reviewed as well as the source changes?
> 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
I don't understand. Is this file generated or manually edited? If the
former, why does having it in the repository add anything new when you
can (and with appropriate Makefile magic will) always run the generator
after pulling changes to source files? If the latter, why does the
subject say it's generated?
[Qemu-devel] [PATCH 10/17] Makefile: add infrastructure to incorporate qidl-generated files, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 15/17] Makefile: add qidl-generation of vmstate field descriptions, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 14/17] qidl: add qidl-based generation of vmstate field bindings, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for rtc, Michael Roth, 2012/06/04
Re: [Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for rtc, Avi Kivity, 2012/06/05
[Qemu-devel] [PATCH 12/17] rtc: add a QOM property for accessing device state, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 13/17] rtc: add _version() qidl annotations, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 16/17] qidl: add qidl-generated vmstate fields for rtc, Michael Roth, 2012/06/04
- Re: [Qemu-devel] [PATCH 09/17] rtc: add qc annotations, (continued)