Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 01/25/2011 10:47 PM, Daniel Veillard wrote:
> On Mon, Jan 24, 2011 at 03:00:38PM -0600, 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.
>>
>> 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
>>
>> I see this series as the first step, followed by converting the I/O loop to
>> a GMainLoop instance.  Once we're there, we can start making deeper use of
>> GObjects including converting QDev to a GObject hierarchy.
>>      
>    Hum, one of the reason I tried to avoid glib dependancies on my own
> libraries code is the behaviour on memory allocation error, unless that
> changed (unlikely) or my recollection is wrong (more likely) glib does
> a direct exit() on memory allocation errors. This might be fine for QEmu
> as a standalone program but may turn a disaster if standalone libraries
> are made out of it and expected for reuse say by libvirt(d).
>    

We have independently done the same thing in QEMU and as such would face 
the same "problem" either way.

Quite a debate could be had on the merits of this.  For QEMU, we made 
this decision for practical purposes.  We did not handle malloc failures 
consistently so adopting a consistent behavior eliminated the 
possibility of NULL pointer dereferences which are exploitable.

Regards,

Anthony Liguori

>    I just want to raise that point as it's a rather fundamental decision
> of the glib/Gnome stack, which was a fine decision to take in the context
> of writing GUI framework, but is really a poor one for implementing low level
> or server infrastructure,
>
> Daniel
>
>