From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFq6R-0004yA-Uc for qemu-devel@nongnu.org; Wed, 13 Mar 2013 14:08:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFq6Q-0000F0-GO for qemu-devel@nongnu.org; Wed, 13 Mar 2013 14:08:39 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:35995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFq6Q-0000ET-8V for qemu-devel@nongnu.org; Wed, 13 Mar 2013 14:08:38 -0400 Date: Wed, 13 Mar 2013 14:08:34 -0400 (EDT) From: Paolo Bonzini Message-ID: <1447652481.7556290.1363198114363.JavaMail.root@redhat.com> In-Reply-To: <87d2v3b2s1.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 > 1) It has no facility for timer events Yup, it's on the todo list. > 2) It's tied to file descriptors (only a problem for win32) The other way round: it's not tied to file descriptors for win32, which is already a problem for e.g. networked backends. main-loop.c has the code that is needed, but it's low on the todo list. Note that tap-win32 for example doesn't need this. > 3) The fd support is tied to read/write without an extensibility > mechanism for other fd events Yes. Though internally it uses g_poll, so it's "just" a matter of defining the right API. > 4) It's got no mechanism to interact with signals signalfd? (GSource doesn't have any such mechanism directly). > 5) It's not obvious how we would integrate with polling-based > callbacks like we have in the character layer and networking layer. Isn't io_flush one such mechanism? Right now it applies to both io_read and io_write, but really it is never used for io_write. Also, this and (3) might be the same problem. > So I agree it's simple but I don't think it can reasonably stay simple. > I think if we added all of the above, the best we would expect to end > up with is something that looked like glib. > > As it stands, the lack of (5) would make it extremely difficult to > convert the networking layer. Quite possible, I've never looked very much at the networking layer. Paolo > Regards, > > Anthony Liguori > > > > >>> 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 >