[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib |
Date: |
Tue, 25 Jan 2011 12:04:33 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- [Qemu-devel] [PATCH 5/7] threads: get rid of QemuCond and teach callers about GCond, (continued)
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
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Aurelien Jarno, 2011/01/25
Message not available
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Johannes Stezenbach, 2011/01/26