From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52932 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phjo3-0006c9-RW for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:23:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phjnz-0006AN-T0 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:23:39 -0500 Received: from hall.aurel32.net ([88.191.126.93]:38462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phjnz-00069w-JW for qemu-devel@nongnu.org; Tue, 25 Jan 2011 09:23:35 -0500 Date: Tue, 25 Jan 2011 15:23:27 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib Message-ID: <20110125142327.GH23331@hall.aurel32.net> References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Paulo Bonzini , Arun Bharadwaj 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. > > I've spent the past few months working on C++ integration for QEMU. I'm more > convinced than ever that we desperately in need of structured object oriented > mechanisms to be successful but am pretty strongly convinced that incremental > additional of C++ is not going to be successful. > > On the other hand, while GObjects are uglier and require a lot of template code, > there's more than enough structure that I think it can guide us into a much > better object model implementation. > > There is some ugliness. GLib does not abstract signals because they're very > non-portable but QEMU makes extensive use of signaling. I don't think it's > a major issue but some of the ugliness in this series is due to that fact. > > This series is only lightly tested but also mostly mechanical. I'm pretty > confused by the way tcg_halt_cond and friends works so I'm fairly sure I broke > that (for non-threaded TCG). This patch series indeed doesn't work at all on TCG. The CPU emulation never starts and the processed is only killable with -9. Surprisingly it works with io_thread disabled, while without this patch series, QEMU both work with and without io_thread (maybe with some overhead, but at least it works). That's a pitty given the main loop is critical for TCG, and I am really fearing regressions or slowdown that we should detect before going to far in this direction. Note that contrary to KVM, it's easy to test TCG as you don't need any extension on your CPU. The same images can be used. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net