From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38912 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhUTy-0007UP-Id for qemu-devel@nongnu.org; Mon, 24 Jan 2011 17:01:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhUTx-0000li-6W for qemu-devel@nongnu.org; Mon, 24 Jan 2011 17:01:54 -0500 Received: from mail-iw0-f173.google.com ([209.85.214.173]:35073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhUTx-0000le-2M for qemu-devel@nongnu.org; Mon, 24 Jan 2011 17:01:53 -0500 Received: by iwn40 with SMTP id 40so4658262iwn.4 for ; Mon, 24 Jan 2011 14:01:52 -0800 (PST) Message-ID: <4D3DF6C0.9040809@codemonkey.ws> Date: Mon, 24 Jan 2011 16:01:36 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <4D3DEEE1.90904@redhat.com> In-Reply-To: <4D3DEEE1.90904@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: Paolo Bonzini Cc: Arun Bharadwaj , Paul Brook , Marcelo Tosatti , qemu-devel@nongnu.org, Stefan Hajnoczi On 01/24/2011 03:28 PM, Paolo Bonzini wrote: > 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). Not sure how much either of these matter, but we should at least drop QObject and convert our JSON parser to use GValues such that we can treat the JSON parser as a stand alone component. >> - 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've been thinking about this myself. I think slirp is probably best handled as a GSource as much as I don't want to do it. I don't see another option. We can't use the g_timeout_source directly because the interval is milliseconds. Since our clock mechanisms all use signals to generate clock events, I think we can tie it all to a pipe() and just use a GIOChannel to generate events. Obviously, implementing a GSource is the best long term approach but I think there's a reasonable short term one. Regards, Anthony Liguori > 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 >