From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48541 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phhdr-0003C7-L6 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 07:05:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phhdq-0004Ue-C0 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 07:04:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phhdq-0004U9-5J for qemu-devel@nongnu.org; Tue, 25 Jan 2011 07:04:58 -0500 Date: Tue, 25 Jan 2011 12:04:33 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib Message-ID: <20110125120433.GA13398@redhat.com> References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <4D3EB94E.3080406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D3EB94E.3080406@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Anthony Liguori , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Arun Bharadwaj , Paulo Bonzini 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. > > So we could do all the high-level stuff such as config parsing in a > high-level language some day. > Or if really crazy, you could write new devices in Javascript :-) Could be useful for rapid prototyping of new ideas at least. Regards, Daniel