From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYef-0001sO-TG for qemu-devel@nongnu.org; Fri, 12 Apr 2013 03:44:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQYed-0002hY-AF for qemu-devel@nongnu.org; Fri, 12 Apr 2013 03:44:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYed-0002hU-05 for qemu-devel@nongnu.org; Fri, 12 Apr 2013 03:44:15 -0400 Date: Fri, 12 Apr 2013 09:44:06 +0200 From: Stefan Hajnoczi Message-ID: <20130412074406.GB30834@stefanha-thinkpad.redhat.com> References: <1365399368-26967-1-git-send-email-pingfank@linux.vnet.ibm.com> <20130409152246.GC12456@stefanha-thinkpad.redhat.com> <20130410115520.GA28480@stefanha-thinkpad.muc.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Liu Ping Fan , Stefan Hajnoczi , qemu-devel , mdroth , Anthony Liguori , Jan Kiszka , Paolo Bonzini 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 wrote: > > On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan wrote: > >> On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi 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 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