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




Reply via email to