qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
Date: Tue, 25 Jan 2011 15:23:27 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]