From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rawk8-00058G-E1 for qemu-devel@nongnu.org; Wed, 14 Dec 2011 16:52:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rawk6-0000TT-MS for qemu-devel@nongnu.org; Wed, 14 Dec 2011 16:52:04 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:46665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rawk6-0000TK-FQ for qemu-devel@nongnu.org; Wed, 14 Dec 2011 16:52:02 -0500 Received: by yenm6 with SMTP id m6so1144519yen.4 for ; Wed, 14 Dec 2011 13:52:01 -0800 (PST) Message-ID: <4EE91A7E.3060302@codemonkey.ws> Date: Wed, 14 Dec 2011 15:51:58 -0600 From: Anthony Liguori 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> <4EE8F0D4.3050300@weilnetz.de> <4EE8F2EB.4090106@us.ibm.com> <4EE90BAE.4040108@weilnetz.de> <4EE90D02.3050905@codemonkey.ws> <4EE91496.5010304@weilnetz.de> In-Reply-To: <4EE91496.5010304@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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org, Avi Kivity On 12/14/2011 03:26 PM, Stefan Weil wrote: > Am 14.12.2011 21:54, schrieb Anthony Liguori: >> On 12/14/2011 02:48 PM, Stefan Weil wrote: >>> Am 14.12.2011 20:03, schrieb Anthony Liguori: >>>> On 12/14/2011 12:54 PM, Stefan Weil wrote: >>>>> Am 14.12.2011 17:34, schrieb malc: >>>>>> On Wed, 14 Dec 2011, Anthony Liguori wrote: >>>>>> >>>>>>> GTK/glib uses a convenient of: >>>>>>> >>>>>>> typedef struct _CamelCase CamelCase; >>>>>>> >>>>>>> The reason that they use a separate struct name is that in C++, the struct >>>>>>> namespace not a separate namespace from the type namespace. This is >>>>>>> actually a >>>>>>> reasonable policy for QEMU to adopt as we eventually start exporting C >>>>>>> libraries >>>>>>> that may be consumed by C++ programs. >>>>>>> >>>>>>> I think the use of _ does not violate the C specification as the struct >>>>>>> namespace is not the same as the type namespace which is what the C spec >>>>>>> refers >>>>>>> to if I understand it correctly. >>>>>> >>>>>> It does violate the standard _ followed by upper case letter is reserved >>>>>> in all contexts. >>>>> >>>>> sCamelCase instead of _CamelCase seems to work, too. >>>> >>>> Are you sure? >>>> >>>> Take a look at: >>>> >>>> html/QEMU-Memory-API.html#MemoryRegionOps >>>> >>>> It's supposed to look like: >>>> >>>> http://wiki.qemu.org/docs-internal/QEMU-Memory-API.html#MemoryRegionOps >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>> >>> I took a look. The html documentation claims that there is a >>> "struct MemoryRegion". There isn't, it's a typedef. >>> Users of the API should use a pointer to a MemoryRegion >>> without knowing details of MemoryRegion, not even whether >>> it is a struct, long or something else. >> >> You should see documentation for each parameter. >> >> At this point, I just patched gtk-doc such that now gtk-doc doesn't require >> the underscore. >> >> At least the latest version of gtk-doc definitely requires an underscore so >> having a patched version will be necessary. >> >> Regards, >> >> Anthony Liguori >> > > > See http://qemu.weilnetz.de/gtkdoc/QEMU-Memory-API.html for > the result which I get with latest QEMU sources, your patch > series v2 and gtk-doc from Debian Squeeze. 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 > > Regards, > Stefan Weil > >