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

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> 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. :)

Okay, deeper isn't that hard apparently.

There's not a lot in AioContext.  Specifically:

1) It has no facility for timer events

2) It's tied to file descriptors (only a problem for win32)

3) The fd support is tied to read/write without an extensibility
mechanism for other fd events

4) It's got no mechanism to interact with signals

5) It's not obvious how we would integrate with polling-based callbacks
like we have in the character layer and networking layer.

So I agree it's simple but I don't think it can reasonably stay simple.
I think if we added all of the above, the best we would expect to end
up with is something that looked like glib.

As it stands, the lack of (5) would make it extremely difficult to
convert the networking layer.

Regards,

Anthony Liguori

>
>>> 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