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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

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