From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:34458)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaxSX-0001na-5y
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 17:37:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaxSV-0001AC-DA
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 17:37:57 -0500
Received: from mail-yx0-f173.google.com ([209.85.213.173]:37421)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaxSV-0001A1-9B
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 17:37:55 -0500
Received: by yenm6 with SMTP id m6so1175697yen.4
	for <qemu-devel@nongnu.org>; Wed, 14 Dec 2011 14:37:54 -0800 (PST)
Message-ID: <4EE9253F.2000203@codemonkey.ws>
Date: Wed, 14 Dec 2011 16:37:51 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1323879637-16901-1-git-send-email-aliguori@us.ibm.com>	<1323879637-16901-2-git-send-email-aliguori@us.ibm.com>	<alpine.LNX.2.00.1112142033410.2501@linmac>	<4EE8F0D4.3050300@weilnetz.de>	<4EE8F2EB.4090106@us.ibm.com>	<4EE90BAE.4040108@weilnetz.de>	<4EE90D02.3050905@codemonkey.ws>	<4EE91496.5010304@weilnetz.de>	<4EE91A7E.3060302@codemonkey.ws>
	<4EE921E6.9070700@weilnetz.de>
In-Reply-To: <4EE921E6.9070700@weilnetz.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/4] memory: make memory API parsable by
 gtkdoc-scan
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Weil <sw@weilnetz.de>
Cc: qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>

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
>
>