From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54756 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxKto-0006Lm-9o for qemu-devel@nongnu.org; Wed, 09 Mar 2011 10:02:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxKtn-0004z7-56 for qemu-devel@nongnu.org; Wed, 09 Mar 2011 10:02:04 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.143]:42254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxKtn-0004yn-2V for qemu-devel@nongnu.org; Wed, 09 Mar 2011 10:02:03 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p29Efa3Z026552 for ; Wed, 9 Mar 2011 09:41:40 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id C96FB38C803B for ; Wed, 9 Mar 2011 10:01:50 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p29F1qsM280078 for ; Wed, 9 Mar 2011 10:01:52 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p29F1qGe008253 for ; Wed, 9 Mar 2011 10:01:52 -0500 Message-ID: <4D77965A.6010106@linux.vnet.ibm.com> Date: Wed, 09 Mar 2011 09:01:46 -0600 From: Michael Roth MIME-Version: 1.0 References: <1299528642-23631-1-git-send-email-mdroth@linux.vnet.ibm.com> <1299528642-23631-2-git-send-email-mdroth@linux.vnet.ibm.com> <4D778787.1020606@redhat.com> <4D778A95.1000808@linux.vnet.ibm.com> <4D7790EB.1050206@redhat.com> In-Reply-To: <4D7790EB.1050206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v7 01/16] Move code related to fd handlers into utility functions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, Jes.Sorensen@redhat.com, aliguori@linux.vnet.ibm.com, markus_mueller@de.ibm.com On 03/09/2011 08:38 AM, Paolo Bonzini wrote: > On 03/09/2011 03:11 PM, Michael Roth wrote: >> >> In the context of virtagent I would agree. The only complication there >> being that a large part of the event-driven code (the async read/write >> handlers for instance) is shared between virtagent and the host. > > What exactly? The dependencies in 16/16 give: > > qemu-tool.o qemu-error.o qemu-sockets.c $(oslib-obj-y) $(trace-obj-y) > $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o > qemu-timer.o These objs: virtagent.o virtagent-server.o virtagent-common.o virtagent-transport.o virtagent-manager.o Are shared by qemu and qemu-va. virtagent.o uses the common timer infrastructure introduced in patch 3, and virtagent-transport/virtagent-common use the iohandler stuff from patch 1/2. On the host, qemu's event loop drives them, and on the guest, qemu-va's event loop drives them. Not sure what level of sharing we can maintain with 2 different event loops. I'm sure it's doable, just not sure what it would end up looking like. I should note that initially all the qemu_set_fd_handler() stuff was wrapped to provide compatibility between separate event loop implementations in qemu/qemu-va. Sharing the event loop code was a widely-held consensus from earlier reviews. I'm not sure glib is so nice that it's worth back-peddling on that. And if we do eventually make qemu's event loop glib-based, consumers of the common code here would get migrated over for free. > > Compared to other tools, only qemu-sockets.c is added (and timers); > overall it is quite self contained and interfaces well with glib's > GIOChannels, which provide qemu_set_fd_handler-equivalent functionality. > > In addition, qemu iohandlers have a lot of unwritten assumptions, for > example on Win32 they only work with sockets and not other kinds of file > descriptors. Hmm, that could be a problem... It seems like a more general one though, that might benefit consumers other than virtagent. So if this is addressed at some point, consumers of the common infrastructure proposed here would all benefit. > > Paolo