From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rqnzp-0006a0-LU for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:45:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rqnzn-0007Kd-VH for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:45:49 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42334 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rqnzn-0007KP-MP for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:45:47 -0500 Message-ID: <4F22C629.3040703@suse.de> Date: Fri, 27 Jan 2012 16:43:37 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com> <1327433600-7403-5-git-send-email-aliguori@us.ibm.com> <4F20746F.1000905@suse.de> <4F207634.4050700@codemonkey.ws> <4F22BD38.50201@suse.de> <4F22C5CB.70209@codemonkey.ws> In-Reply-To: <4F22C5CB.70209@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Am 27.01.2012 16:42, schrieb Anthony Liguori: > On 01/27/2012 09:05 AM, Andreas F=E4rber wrote: >> Am 25.01.2012 22:37, schrieb Anthony Liguori: >>> On 01/25/2012 03:30 PM, Andreas F=E4rber wrote: >>>> Am 24.01.2012 20:32, schrieb Anthony Liguori: >>>>> This class provides the main building block for QEMU Object Model >>>>> and is >>>>> extensively documented in the header file. It is largely inspired = by >>>>> GObject. >>>>> >>>>> Signed-off-by: Anthony Liguori >>>>> --- >>>>> v1 -> v2 >>>>> - remove printf() in type registration >>>>> - fix typo in comment (Paolo) >>>>> - make Interface private >>>>> - move object into a new directory and move header into >>>>> include/qemu/ >>>> >>>> Some of us had expressed concerns over introducing include/. Any >>>> particular reason you're doing it still? >>> >>> Because it's a great idea and I thought everyone loved it? >>> >>> Can you point me to the concerns raised, I'll go back and look. I >>> didn't think it was contentious... >> >> Can't find it right now (stupid search keyword!) >=20 > No problem. >=20 >> but I remember having a >> discussion around whether these are actually "public" APIs because to >> date we have always claimed that all APIs are internal and no guarante= es >> are made. IMO moving headers to an include/ dir marks a change of that >> policy because header in include/ usually get installed alongside a >> library so if we do it we should do it conciously. >> >> Thing is, headers that are private to one part of code are public to >> another. It's not black and white. E.g., hw -> IDE -> AHCI -> ICH9. >> Whenever there's multiple subclasses code needs to be shared; it >> shouldn't usually be poked at from the outside though in favor of >> qdev/QOM properties. >> >> Personally, I find it more handy to find pci_dec.c and pci_dec.h in th= e >> same directory in Nautilus/gedit/whatever (but bad example because I'm >> working on making that header go away). On the other hand compared to >> like r955 we have seen a huge inflation in hw/ files. >> I can live with it either way, and as Paolo says, it can easily be >> changed later with git-mv. And #include "qemu/foo.h" sounds fair. >=20 > When I think of include/, I think of "internally public" headers. IOW, > things that are meant to be shared in other parts of QEMU. For > instance, something like qemu-queue.h. >=20 > In fact, there are 25 header files in $SRCDIR that are in the form > qemu-$file.h. They could (and should) probably be moved to > include/qemu/$file.h Okay, agree. Regards, Andreas >=20 > As we introduce more directory structure, having a single include > directory will be very handy. For instance, pci_dec.c may move to > drivers/ppc/pci_dec.c. But having pci_dec.h in include/qemu means that > we don't have to worry about very long #include paths. >=20 > Regards, >=20 > Anthony Liguori >=20 >> >> For these new "public" headers I'd be interested in finding a solution >> where we can all easily collaborate on the documentation though. Right >> now we need to trust you to get the markup right. >> >> Andreas >> >>> To summarize my rationale for it: >>> >>> 1) It avoids all of the non-sense with conflicting system headers >>> (because we -Iinclude and the headers live in include/qemu) >>> >>> 2) It establishes what are public functions for use in other parts = of >>> qemu vs. private headers (which we currently use based on ad-hoc nami= ng >>> schemes like block_int.h). >>> >>> 3) I think the kernel serves as an existence proof that this method= to >>> manage headers works really well in practice. >>> >>> Regards, >>> >>> Anthony Liguori >> >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg