|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib |
Date: | Tue, 25 Jan 2011 12:51:42 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Red Hat/3.1.7-3.el6_0 Thunderbird/3.1.7 |
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.
<dream>So we could do all the high-level stuff such as config parsing in a high-level language some day.
</dream>
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.
Agree. I doubt switching to C++ will fly. But using glib has pretty good chances to be a big success long-term.
I think we should get 0.14 out of the door before starting to work on that though ;)
cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |