From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42281 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhTxS-0001JZ-Gp for qemu-devel@nongnu.org; Mon, 24 Jan 2011 16:28:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhTxQ-0002U5-Oa for qemu-devel@nongnu.org; Mon, 24 Jan 2011 16:28:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhTxQ-0002Ts-Hk for qemu-devel@nongnu.org; Mon, 24 Jan 2011 16:28:16 -0500 Message-ID: <4D3DEEE1.90904@redhat.com> Date: Mon, 24 Jan 2011 22:28:01 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Arun Bharadwaj , Marcelo Tosatti , qemu-devel@nongnu.org, Stefan Hajnoczi , Paul Brook On 01/24/2011 10:00 PM, 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 > - IO library > - rich data structure support These are where GLib shines. > - INI parser Not compatible with our config files anyway. > - JSON parser I think our JSON parser is much better than JsonGlib (which isn't anyway a part of GLib proper). > - generic type system > - object oriented infrastructure > - module system > - introspection to enable support for dynamic language bindings See below. > 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. I am not sure how these other bits will look like and maybe it won't make sense at all, but it doesn't matter. The bits you posted are already a step in the right direction IMHO, and the same goes for converting the I/O loop to GMainLoop if you can pull that :) and using glib's thread pool. (Regarding GMainLoop, my main worry is that we'd have to reinvent a lot of GSources to integrate properly with slirp, with QEMU's multiple clocks, and so on. And GSources are black magic...). I'd also add to the benefits a good multi-threaded memory allocator. A small qualm I have is that glib (and GNOME in general) is one of the hardest pieces of free software to contribute to in my experience. I have patches which had multiple acks and are still languishing after a year or so. Still not an excuse for NIH. Paolo