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

[Anthony Liguori <aliguori@us.ibm.com>]

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