From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38196 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PinuY-00035f-EF for qemu-devel@nongnu.org; Fri, 28 Jan 2011 07:58:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PinuW-0000c7-Mz for qemu-devel@nongnu.org; Fri, 28 Jan 2011 07:58:46 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:59490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PinuW-0000bv-KT for qemu-devel@nongnu.org; Fri, 28 Jan 2011 07:58:44 -0500 Received: by gwaa12 with SMTP id a12so1173893gwa.4 for ; Fri, 28 Jan 2011 04:58:43 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4D42BD7D.8020004@redhat.com> Date: Fri, 28 Jan 2011 13:58:37 +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> In-Reply-To: <1296199312-26334-20-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> 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 08:21 AM, Yoshiaki Tamura wrote: > > + /* check ft_mode option */ > + p = strstr(uri, "ft_mode"); > + if (p&& !strcmp(p, "ft_mode")) { > + ft_mode = FT_INIT; > + } > + This works for TCP mode, but: 1) I am not sure what would happen with -incoming exec; 2) it is tricky! :) It works only because anything after the port is truncated by parse_host_port. Is there any reason why the code cannot be in tcp_start_incoming_migration, where we know the URI has the right scheme? Alternatively you could put it _before_ the scheme, like "kemari:tcp:host:port". Paolo