[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib |
Date: |
Wed, 26 Jan 2011 21:23:52 +0000 |
On Wed, Jan 26, 2011 at 3:53 PM, Anthony Liguori
<address@hidden> wrote:
> 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.
Both g_malloc() and g_try_malloc() are available where g_try_malloc()
returns NULL on failure. g_malloc() matches qemu_malloc() exit
behavior today but in the future it would be possible to use
g_try_malloc() for proper out-of-memory handling.
But I think you're pointing out that glib uses g_malloc() internally.
That is a design flaw and basically makes g_try_malloc() useless.
Stefan
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Johannes Stezenbach, 2011/01/26