From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPB5v-0008S7-SW for qemu-devel@nongnu.org; Thu, 26 Sep 2013 08:55:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPB5p-0001b9-SI for qemu-devel@nongnu.org; Thu, 26 Sep 2013 08:54:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPB5p-0001b1-Kq for qemu-devel@nongnu.org; Thu, 26 Sep 2013 08:54:53 -0400 Message-ID: <52442EA2.7020300@redhat.com> Date: Thu, 26 Sep 2013 14:54:58 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1380119568-5530-1-git-send-email-lilei@linux.vnet.ibm.com> <5242FAE8.6030807@redhat.com> <52442C16.7000200@linux.vnet.ibm.com> In-Reply-To: <52442C16.7000200@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lei Li Cc: aarcange@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, mrhines@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, anthony@codemonkey.ws, lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com Il 26/09/2013 14:44, Lei Li ha scritto: >> >> The basis of your code will still be the socket-based QEMUFile, but >> you'll need your own QEMUFile since you're adding Unix-specific >> functionality. For this it is not a problem to have two copies the >> QEMUFile code for sockets, one in savevm.c and one in migration-unix.c. > > Have two copies of the QEMUFile code for sockets, do you mean in my own > QEMUFile, say QEMUFilePipe, includes both the copy of QEMUFileSocket > code (like get_fd, get_buffer, writev_buffer..) and the Unix-specific > functionality code that override these three hooks like your suggestions > above? Yes (the name could be either QEMUFilePipe or QEMUFileUnix, I guess). > I guess 'migration-unix.c' you typed is 'migration-local.c', right? I wasn't sure of the reason why 'migration-unix.c' and 'migration-local.c' were split, since now the choice is done with a capability rather than a different protocol. Thanks, Paolo