qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib
Date: Mon, 24 Jan 2011 22:28:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

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).

  - 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'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]