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
