Am 05.06.2012 18:21, schrieb Michael Roth: > On Tue, Jun 05, 2012 at 11:25:01AM +0200, Kevin Wolf wrote: >> Am 05.06.2012 03:00, schrieb Michael Roth: >>> This is an import of Anthony's qidl compiler, with some changes squashed >>> in to add support for doing the visitor generation via QEMU's qapi code >>> generators rather than directly. >>> >>> Documentation has been imported as well, as is also viewable at: >>> >>> https://github.com/aliguori/qidl/blob/master/qc.md >>> >>> This will be used to add annotations to device structs to aid in >>> generating visitors that can be used to serialize/unserialize them. >>> >>> Signed-off-by: Michael Roth <mdr...@linux.vnet.ibm.com> >>> --- >>> scripts/qc.md | 331 ++++++++++++++++++++++++++++++++++++++ >>> scripts/qc.py | 494 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> 2 files changed, 825 insertions(+), 0 deletions(-) >>> create mode 100644 scripts/qc.md >>> create mode 100755 scripts/qc.py >>> >>> diff --git a/scripts/qc.md b/scripts/qc.md >>> new file mode 100644 >>> index 0000000..4cf4b21 >>> --- /dev/null >>> +++ b/scripts/qc.md >> >> I think docs/ would be a better place than scripts/ >> >>> +Getting Started >>> +--------------- >>> + >>> +The first step is to move your device struct definition to a header file. >>> This >>> +header file should only contain the struct definition and any preprocessor >>> +declarations you need to define the structure. This header file will act >>> as >>> +the source for the QC IDL compiler. >>> + >>> +Do not include any function declarations in this header file as QC does not >>> +understand function declarations. >> >> Couldn't we use a header file (or even source file) that has some magic >> markers for the IDL compiler? Like: >> >> ... random stuff ... >> >> /* QIDL START */ >> struct Foo { >> ... >> }; >> /* QIDL END */ >> >> ... random stuff ... >> >> Adding a new header file for each device really doesn't look like a >> desirable thing, and this way it could be avoided. > > We could always make the compiler smarter (Anthony has already done > so apparently), and in the version posted here the compiler actually > scans line-by-line for the "qc_declaration" annotation before it begins > processing the annotated structure, so it behaves much like you're > suggestion. > > The main reason device state needs to be moved to a seperate file is > because the generated visitors need to access that device state. > > The only way I can think of getting around this is to do nasty things > like adding an > > #include "qapi-generated/mc146818rtc-qapi-visit.c"; > > in hw/mc146818rtc.c.
If the alternative is making private structs public, which is even nastier IMHO, this might be the lesser evil. (And I agree with Paolo that Anthony's version is a bit too much magic and doesn't really make it cleaner) Kevin
