qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib
Date: Mon, 24 Jan 2011 16:01:36 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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





reply via email to

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