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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Jan 25, 2011 at 12:51:42PM +0100, Gerd Hoffmann wrote:
> On 01/24/11 22:00, 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.
> 
> Somehow this idea crossed my mind as well while thinking about the
> io handler issue.  Why limit yourself to steal ideas from glib if we
> can just use the library instead?
>
> >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
> 
> Even if we only offload some portability issues to glib and use the
> gmainloop we'll have a net win I suspect.  Using gmainloop will make
> it alot easier to integrate third party libs which quite often offer
> glib integration.  We could easily use avahi to announce our vnc
> server via mdns/zeroconf/bonjour for example.  Also I'd be tempted
> to just rewrite pulseaudio support using the glib support in pulse.
> 
> Turn all qemu internals into gobjects is certainly non-trivial,
> especially managing the transition phase.  But nevertheless it
> probably is worth the effort long-term as glib has all sorts of
> language bindings.

If your internals are all properly designed & encapsulated
GObjects and you enable GObject Introspection, you'll get
direct access from non-C languages more or less for free
these days. You won't have to actually write language bindings
for any of your objects - worst case there is a completely
automatic code generator, but for most dynamic languages not
even that is required anymore in GObject.

Of course getting QEMU internals to be properly encapsulated
objects is a non-trivial task, but it can continue to be done
incrementally of course, and using a more structured object
system would help to enforce rigourous design practice in this
respect.

> <dream>
> So we could do all the high-level stuff such as config parsing in a
> high-level language some day.
> </dream>

Or if really crazy, you could write new devices in Javascript :-)
Could be useful for rapid prototyping of new ideas at least.

Regards,
Daniel