On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan <qemul...@gmail.com> wrote: > On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi <stefa...@redhat.com> 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 <stefa...@redhat.com> >>> 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. Stefan