From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33254 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhkvI-0007CO-P6 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:35:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhkvH-0007qU-ES for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:35:12 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:52459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhkvH-0007qL-9J for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:35:11 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0PFKxaQ005854 for ; Tue, 25 Jan 2011 08:20:59 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p0PFZ9R8239390 for ; Tue, 25 Jan 2011 08:35:09 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0PFZ97w021799 for ; Tue, 25 Jan 2011 08:35:09 -0700 Message-ID: <4D3EEDAA.2020309@linux.vnet.ibm.com> Date: Tue, 25 Jan 2011 09:35:06 -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> <20110125142327.GH23331@hall.aurel32.net> In-Reply-To: <20110125142327.GH23331@hall.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Anthony Liguori , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Paulo Bonzini , Arun Bharadwaj On 01/25/2011 08:23 AM, Aurelien Jarno 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. >> >> 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. > Yeah, it's fixable and I will fix it. I'm still trying to understand the I/O thread interactions with TCG. Regards, Anthony Liguori