From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFpaa-0003lJ-Vz for qemu-devel@nongnu.org; Wed, 13 Mar 2013 13:35:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFpaU-0006Ss-74 for qemu-devel@nongnu.org; Wed, 13 Mar 2013 13:35:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFpaT-0006SX-UU for qemu-devel@nongnu.org; Wed, 13 Mar 2013 13:35:38 -0400 Message-ID: <5140B8E0.8040302@redhat.com> Date: Wed, 13 Mar 2013 18:35:28 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363154346-14827-1-git-send-email-qemulist@gmail.com> <51405BEA.6080109@redhat.com> <87hakfiild.fsf@codemonkey.ws> <5140A76E.1080902@redhat.com> <87vc8vrz6i.fsf@codemonkey.ws> In-Reply-To: <87vc8vrz6i.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: mdroth , Stefan Hajnoczi , "Michael S. Tsirkin" , Liu Ping Fan , qemu-devel@nongnu.org Il 13/03/2013 18:23, Anthony Liguori ha scritto: > I think the nesting is also a bit strange. Nesting's gone since we added coroutines. :) >> and AioContext's code is vastly simpler than GMainLoop's. > > For now. Fair enough. :) >> AioContext is also documented and unit tested, with tests >> for both standalone and GSource operation. Unit tests for AioContext >> users are trivial to write, we have one in test-thread-pool. >> >>> Did you have a specific concern with using glib vs. AioContext? Is it >>> about reusing code in the block layer where AioContext is required? >> >> In the short term yes, code duplication is a concern. We already have >> two implementation of virtio. > > I share your concern but in the opposite direction. We have three main > loops today. Yes, and two of them (main-loop.c/qemu-timer.c and async.c) can be merged. >> I would like the dataplane virtio code to >> grow everything else that needs to be in all dataplane-style devices >> (for example, things such as setting up the guest<->host notifiers), and >> the hw/virtio.c API implemented on top of it (or dead altogether). >> Usage of AioContext is pretty much forced by the block layer. > > I don't think that AioContext is the right answer because it makes it > too easy to shoot yourself in the foot. See above, if nesting is the problem it's gone. Paolo