On 12/14/2011 04:23 PM, Stefan Weil wrote:
Am 14.12.2011 22:51, schrieb Anthony Liguori:
Look carefully at:
http://qemu.weilnetz.de/gtkdoc/QEMU-Memory-API.html#MemoryRegionOps
vs:
http://wiki.qemu.org/docs-internal/QEMU-Memory-API.html#MemoryRegionOps
There's a significant difference :-)
Regards,
Anthony Liguori
I tried the following declaration:
typedef struct sMemoryRegionOps {
uint64_t (*read)(void *opaque,
target_phys_addr_t addr,
unsigned size);
void (*write)(void *opaque,
target_phys_addr_t addr,
uint64_t data,
unsigned size);
enum device_endian endianness;
MemoryRegionGuestConstraints valid;
MemoryRegionInternalConstraints impl;
const MemoryRegionPortio *old_portio;
const MemoryRegionMmio old_mmio;
} MemoryRegionOps;
See the result here:
http://qemu.weilnetz.de/gtkdoc4/QEMU-Memory-API.html#MemoryRegionOps
Interesting, but it wouldn't be possible to do a forward declaration?
I think my patch to gtk-doc (make _ optional) seems reasonable and I think
that's a bit nicer than doing struct sCamelCase too.
That doesn't help with C++ compatibility but now that it is not in favor of my
argument, I no longer care about it ;-) (j/k)
Regards,
Anthony Liguori
Regards,
Stefan Weil