From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=53745 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PhhRF-0003jr-3L
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:51:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PhhRD-0001TT-Nf
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:51:56 -0500
Received: from mx1.redhat.com ([209.132.183.28]:57168)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PhhRD-0001T6-Bj
	for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:51:55 -0500
Message-ID: <4D3EB94E.3080406@redhat.com>
Date: Tue, 25 Jan 2011 12:51:42 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com>
In-Reply-To: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>, Paulo Bonzini <pbonzini@redhat.com>, Arun Bharadwaj <arun@linux.vnet.ibm.com>

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