qemu-devel
[Top][All Lists]
Advanced

[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: Fri, 12 Apr 2013 09:44:06 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Apr 11, 2013 at 08:05:05PM +0800, liu ping fan wrote:
> 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.

So you want to avoid creating many GSources and instead have a single
custom GSource poll many fds?

That sounds like a generic utility so please make it reusable and not
part of slirp code.

Stefan



reply via email to

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