From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57432 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PE4pC-0004EH-Ji for qemu-devel@nongnu.org; Thu, 04 Nov 2010 14:46:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PE4pB-0000ek-FN for qemu-devel@nongnu.org; Thu, 04 Nov 2010 14:46:14 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:51398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PE4pB-0000eX-9D for qemu-devel@nongnu.org; Thu, 04 Nov 2010 14:46:13 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oA4IP4w4002424 for ; Thu, 4 Nov 2010 14:25:04 -0400 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 oA4IkABH315490 for ; Thu, 4 Nov 2010 14:46:10 -0400 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 oA4IkAZU015308 for ; Thu, 4 Nov 2010 14:46:10 -0400 Message-ID: <4CD2FF71.9080802@linux.vnet.ibm.com> Date: Thu, 04 Nov 2010 13:46:09 -0500 From: Michael Roth MIME-Version: 1.0 References: <1288798090-7127-1-git-send-email-mdroth@linux.vnet.ibm.com> <1288827886.2846.76.camel@aglitke> In-Reply-To: <1288827886.2846.76.camel@aglitke> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][RESEND][PATCH v1 00/15] virtproxy: host/guest communication layer List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: abeekhof@redhat.com, agl@linux.vnet.ibm.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com On 11/03/2010 06:44 PM, Adam Litke wrote: > You've got a lot of "objects" interacting with one another in virtproxy. > I think it would help other reviewers if you could describe the > relationships between the entities such as: VPDriver, VPConn, VPChannel, > VPIForward, VPOForward, etc. This patch series is really wiring a lot > of things together. Your documentation could end up as a nice ASCII art > diagram and associated commentary at the top of virtproxy.c. > Hmm, yah, at the very least I should document these a bit better somewhere. virtproxy.c or maybe even docs/virtproxy.txt. For the benefit of anyone reviewing these patches though: VPDriver: encompasses the virtproxy state, which manages connections coming in/out of a data channel between the host and the guest, such as a virtio-serial or isa-serial port. Additional virtproxy/VPDriver instances can be set up to manage additional data channels. In the integrated version of these patches this channel will be accessed via an encapsulated virtproxy character device in the host, or an fd in the guest. VPConn: encapsulates a bit of state, and client fds connected to forwarding sockets/ports that virtproxy set up or server fds that virtproxy established a connection to and is forwarding connections to. VPOForward: encapsulates a listening forwarding port/socket that was passed to it, and an associated service_id. connections to the port/socket cause a VPConn to be set up, and data is proxied to the service on the other end of the channel that this service_id maps to. VPIForward: maps a service_id to a local socket/port.