[Top][All Lists]
[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
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Anthony Liguori, 2011/01/24
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Stefan Hajnoczi, 2011/01/25
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Gerd Hoffmann, 2011/01/25