From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGdq-0004vh-V6 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:11:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYGdj-00066Y-W2 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:11:50 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:61552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGdj-00066L-QC for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:11:43 -0400 Received: by mail-pa0-f46.google.com with SMTP id kx10so4109869pab.33 for ; Thu, 10 Apr 2014 08:11:43 -0700 (PDT) Message-ID: <5346B4A9.7040601@ozlabs.ru> Date: Fri, 11 Apr 2014 01:11:37 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1395888071-28677-1-git-send-email-aik@ozlabs.ru> <53341B8F.7040904@suse.de> <53341E41.7050101@ozlabs.ru> <533422AB.7080106@ozlabs.ru> <53435036.9020901@ozlabs.ru> <53468A29.50404@suse.de> <5346AC43.2060600@ozlabs.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , "qemu-ppc@nongnu.org" , Alexander Graf , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 04/11/2014 12:49 AM, Peter Maydell wrote: > On 10 April 2014 15:35, Alexey Kardashevskiy wrote: >> Then what is the purpose of many, many VMSTATE_.*_EQUAL? > > Often it's backwards compatibility with a previous vmstate > or save/load function set which incorrectly sent data it didn't > need to. > >> And I do not want to send configuration by the proposed patch, I want to >> make sure that the new guest is able to continue. Why exactly is this bad? > > It's not bad, but as several people have now pointed out to you, > you're trying to fix a tiny tiny corner of the real, larger > problem, in a way which isn't going to generalise to actually > fixing the larger problem. So if we took your change then > (a) we still wouldn't be able to support detection of migration > between two systems with mismatched configuration, so it doesn't > really achieve anything > (b) if we ever did manage to fix that we'd have to remove your > change (because that bit of config checking would now be handled > via whatever generic mechanism we implemented), except we probably > couldn't remove it since that would break migration version > compatibility, so we'd end up with a wart we have to carry > around forever Ok, understood. Thanks. ps. yeah, I do not often see the bigger picture, I know :( -- Alexey