From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqAXa-00076b-Nk for qemu-devel@nongnu.org; Wed, 25 Jan 2012 16:38:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqAXZ-00069a-LD for qemu-devel@nongnu.org; Wed, 25 Jan 2012 16:38:02 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:42494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqAXZ-00069T-E0 for qemu-devel@nongnu.org; Wed, 25 Jan 2012 16:38:01 -0500 Received: by dajr28 with SMTP id r28so2944732daj.4 for ; Wed, 25 Jan 2012 13:38:00 -0800 (PST) Message-ID: <4F207634.4050700@codemonkey.ws> Date: Wed, 25 Jan 2012 15:37:56 -0600 From: Anthony Liguori 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> In-Reply-To: <4F20746F.1000905@suse.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit 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: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: qemu-devel@nongnu.org On 01/25/2012 03:30 PM, Andreas Färber 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... 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 naming 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 > > Andreas >