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

[liu ping fan]

On Thu, Apr 11, 2013 at 7:44 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan <address@hidden> wrote:
>> On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi <address@hidden> wrote:
>>> On Wed, Apr 10, 2013 at 03:47:15PM +0800, liu ping fan wrote:
>>>> On Tue, Apr 9, 2013 at 11:22 PM, Stefan Hajnoczi <address@hidden> wrote:
>>>> > On Mon, Apr 08, 2013 at 01:36:03PM +0800, Liu Ping Fan wrote:
>>>> >> This series focus on network backend (excluding slirp). The related 
>>>> >> patch
>>>> >> for core's re-entrant (queue.c net.c) will be sent out separatelly.
>>>> >
>>>> > Are changes required to tap-win32.c?
>>>> >
>>>> Yes, needed. I will modify and verify it on win32.
>>>>
>>>> > Are you working on converting slirp?
>>>> >
>>>> slirp/ is a relative isolated system from net, need I covert it at the
>>>> same time? Will start on it if needed.
>>>
>>> I suggest tackling it so we can be sure there aren't any surprises that
>>> break the new model that you're introducing.
>>>
>> Oh, the slirp event driven mechanism is a little complicated.   I
>> think that it can be fixed with custom-built  GSource prepare and
>> dispatch function.  Finally, each SlirpState associated with a GSource
>> can run on different thread.  Is this extra GSource acceptable?
>
> Yes, a SlirpState should be bound to an event loop.
>
> Is the reason you need new GSource code because slirp uses
> GIOConditions beyond just G_IO_IN/G_IO_OUT?  I think the generic

This is a minor reason. I think the main challenge is that Slirp has
many socket and even worse, the socket number is increased when new
connection need to be set up.

Pingfan
> fdsource GSource (currently called NetClientSource in your patches)
> should support that.  This way fdsource can also be used by other
> socket code in QEMU.
>
> Stefan