[Top][All Lists]

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

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
Date: Thu, 11 Apr 2013 13:44:41 +0200

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
fdsource GSource (currently called NetClientSource in your patches)
should support that.  This way fdsource can also be used by other
socket code in QEMU.


reply via email to

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