From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36023 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi7gs-00022Y-Fz for qemu-devel@nongnu.org; Wed, 26 Jan 2011 10:53:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi7gr-0007iA-9u for qemu-devel@nongnu.org; Wed, 26 Jan 2011 10:53:50 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:36306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi7gr-0007h2-4n for qemu-devel@nongnu.org; Wed, 26 Jan 2011 10:53:49 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0QFfRvR010998 for ; Wed, 26 Jan 2011 08:41:27 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0QFrgVE080180 for ; Wed, 26 Jan 2011 08:53:42 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0QFrff6006065 for ; Wed, 26 Jan 2011 08:53:41 -0700 Message-ID: <4D404384.5080207@linux.vnet.ibm.com> Date: Wed, 26 Jan 2011 09:53:40 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <20110126044710.GU9566@redhat.com> In-Reply-To: <20110126044710.GU9566@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: veillard@redhat.com Cc: Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Paulo Bonzini , Arun Bharadwaj On 01/25/2011 10:47 PM, Daniel Veillard wrote: > On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote: > >> Both the recent I/O loop and threadlet series have me concerned that we're >> digging ourselves deeper into the NIH hole. I think it's time we look at >> something radical to let us borrow more code from existing projects instead of >> reinventing everything through trial and error. >> >> This series introduces a hard dependency on glib. The initial use is portable >> threads but I see this as just the beginning. Glib/Gobject offer many nice >> things including: >> >> - portable threads >> - rich data structure support >> - INI parser >> - JSON parser >> - generic type system >> - object oriented infrastructure >> - IO library >> - module system >> - introspection to enable support for dynamic language bindings >> >> I see this series as the first step, followed by converting the I/O loop to >> a GMainLoop instance. Once we're there, we can start making deeper use of >> GObjects including converting QDev to a GObject hierarchy. >> > Hum, one of the reason I tried to avoid glib dependancies on my own > libraries code is the behaviour on memory allocation error, unless that > changed (unlikely) or my recollection is wrong (more likely) glib does > a direct exit() on memory allocation errors. This might be fine for QEmu > as a standalone program but may turn a disaster if standalone libraries > are made out of it and expected for reuse say by libvirt(d). > We have independently done the same thing in QEMU and as such would face the same "problem" either way. Quite a debate could be had on the merits of this. For QEMU, we made this decision for practical purposes. We did not handle malloc failures consistently so adopting a consistent behavior eliminated the possibility of NULL pointer dereferences which are exploitable. Regards, Anthony Liguori > I just want to raise that point as it's a rather fundamental decision > of the glib/Gnome stack, which was a fine decision to take in the context > of writing GUI framework, but is really a poor one for implementing low level > or server infrastructure, > > Daniel > >