On 06/05/2012 06:00 PM, Peter Maydell wrote:
On 5 June 2012 02:00, Michael Roth<mdr...@linux.vnet.ibm.com> wrote:
+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.
I don't think this is a fantastic idea -- the device struct should be
private to the device, and having it in a standalone header file is
asking for users of the device to illicitly include it and access
internals that they shouldn't. (This could be mitigated with some
kind of naming convention so it's easy to spot bogus includes in
code review, like "mydevice.int.h" or something.)
Another way to solve this problem is having more directory hierarchy and using
public includes (include/qemu) verses private includes
(devices/pci/virtio/virtio_ring.h).
Whatever format we use, we should make sure it has the potential
to be extensible with markup for "this field is a qom property",
I've already added a '_property' marker which can be used to generate QOM static
property listings.
Regards,
Anthony Liguori
"this class foo is a subclass of class bar", "this class has
methods x,y,z" etc, so we can improve our autogeneration later to
cut out repetitive boilerplate like property array definitions,
initializers and wrapper functions.
(I wouldn't object to a not-actually-C syntax definition which
produced a header with the C struct as one of its outputs.)
-- PMM
