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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>