From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58051 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PipYG-0005tw-9e for qemu-devel@nongnu.org; Fri, 28 Jan 2011 09:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PipYE-000255-4c for qemu-devel@nongnu.org; Fri, 28 Jan 2011 09:43:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PipYD-00024n-Rg for qemu-devel@nongnu.org; Fri, 28 Jan 2011 09:43:50 -0500 Message-ID: <4D42D601.9010905@redhat.com> Date: Fri, 28 Jan 2011 15:43:13 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1296199312-26334-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1296199312-26334-20-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4D42BD7D.8020004@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 19/19] migration: add a parser to accept FT migration incoming mode. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yoshiaki Tamura Cc: kwolf@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, ananth@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, blauwirbel@gmail.com, ohmura.kei@lab.ntt.co.jp, avi@redhat.com, psuriset@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com On 01/28/2011 02:53 PM, Yoshiaki Tamura wrote: >> > 1) I am not sure what would happen with -incoming exec; > > Nothing happens if used with other protocols, but I assume you're > mentioning that it's not clear from the code, which makes sense. I assume nothing just because the code for other protocols isn't using ft_mode. However, for -incoming exec the parsing code as it is now would trigger if the executed file ended with "ft_mode". So now I think it should be at the beginning of the scheme for forward compatibility with everything. Is it possible to detect a migration scheme that does not support Kemari, and give an error in that case? Paolo