On 16/02/2018 10:13, Peter Maydell wrote:
> On 14 February 2018 at 12:11, Paolo Bonzini wrote:
>> On 14/02/2018 12:43, Zihan Yang wrote:
>>>
I'm not sure what is the advantage of this change. QEMU is more or less
uniformly using QemuMutex and QemuCond.
>>>
>>> I see. QEMU uses some glib
On 14 February 2018 at 12:11, Paolo Bonzini wrote:
> On 14/02/2018 12:43, Zihan Yang wrote:
>>
>>> I'm not sure what is the advantage of this change. QEMU is more or less
>>> uniformly using QemuMutex and QemuCond.
>>
>> I see. QEMU uses some glib functions, like g_new, g_free, g_hash_table ,
>>
On 14/02/2018 12:43, Zihan Yang wrote:
>
>> I'm not sure what is the advantage of this change. QEMU is more or less
>> uniformly using QemuMutex and QemuCond.
>
> I see. QEMU uses some glib functions, like g_new, g_free, g_hash_table ,
> g_assert and g_poll, so I thought there was a trend for ma
> I'm not sure what is the advantage of this change. QEMU is more or less
> uniformly using QemuMutex and QemuCond.
I see. QEMU uses some glib functions, like g_new, g_free, g_hash_table ,
g_assert and g_poll, so I thought there was a trend for making more use of
glib.
I get the point now.
2018
On 14/02/2018 09:49, Zihan Yang wrote:
> change the mutex member in RAMList structure from QemuMutex to CompatGMutex.
> qemu_mutex_init() is just deleted instead of being replaced with
> g_mutex_init()
> because there is no need to do initialize a mutex that is statically
> allocated.
>
> Signed
change the mutex member in RAMList structure from QemuMutex to CompatGMutex.
qemu_mutex_init() is just deleted instead of being replaced with g_mutex_init()
because there is no need to do initialize a mutex that is statically allocated.
Signed-off-by: Zihan Yang
---
exec.c | 5 ++
