From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqnOu-000466-66 for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:07:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqnOs-0001xF-TK for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:07:40 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40135 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqnOs-0001x4-GD for qemu-devel@nongnu.org; Fri, 27 Jan 2012 10:07:38 -0500 Message-ID: <4F22BD38.50201@suse.de> Date: Fri, 27 Jan 2012 16:05:28 +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> In-Reply-To: <4F207634.4050700@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 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/qem= u/ >> >> Some of us had expressed concerns over introducing include/. Any >> particular reason you're doing it still? >=20 > Because it's a great idea and I thought everyone loved it? >=20 > 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!) 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 guarantees 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 the 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. 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: >=20 > 1) It avoids all of the non-sense with conflicting system headers > (because we -Iinclude and the headers live in include/qemu) >=20 > 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 naming > schemes like block_int.h). >=20 > 3) I think the kernel serves as an existence proof that this method to > manage headers works really well in practice. >=20 > Regards, >=20 > Anthony Liguori --=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