qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib
Date: Wed, 13 Mar 2013 18:35:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3

Il 13/03/2013 18:23, Anthony Liguori ha scritto:
> I think the nesting is also a bit strange.

Nesting's gone since we added coroutines. :)

>> and AioContext's code is vastly simpler than GMainLoop's.
> 
> For now.

Fair enough. :)

>> AioContext is also documented and unit tested, with tests
>> for both standalone and GSource operation.  Unit tests for AioContext
>> users are trivial to write, we have one in test-thread-pool.
>>
>>> Did you have a specific concern with using glib vs. AioContext?  Is it
>>> about reusing code in the block layer where AioContext is required?
>>
>> In the short term yes, code duplication is a concern.  We already have
>> two implementation of virtio.
> 
> I share your concern but in the opposite direction.  We have three main
> loops today.

Yes, and two of them (main-loop.c/qemu-timer.c and async.c) can be merged.

>> I would like the dataplane virtio code to
>> grow everything else that needs to be in all dataplane-style devices
>> (for example, things such as setting up the guest<->host notifiers), and
>> the hw/virtio.c API implemented on top of it (or dead altogether).
>> Usage of AioContext is pretty much forced by the block layer.
> 
> I don't think that AioContext is the right answer because it makes it
> too easy to shoot yourself in the foot.

See above, if nesting is the problem it's gone.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]