From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQcgw-0006zr-BQ for qemu-devel@nongnu.org; Tue, 02 Feb 2016 10:16:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQcgs-0001p5-Do for qemu-devel@nongnu.org; Tue, 02 Feb 2016 10:16:30 -0500 References: <1454347206-23717-1-git-send-email-wei@redhat.com> <1454347206-23717-2-git-send-email-wei@redhat.com> <56B054A8.6020602@msgid.tls.msk.ru> From: Wei Huang Message-ID: <56B0C845.9080602@redhat.com> Date: Tue, 2 Feb 2016 09:16:21 -0600 MIME-Version: 1.0 In-Reply-To: <56B054A8.6020602@msgid.tls.msk.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] ARM: PL061: Misc cleaning fields for PL061 device state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev , Peter Maydell Cc: QEMU Trivial , Igor Mammedov , Shannon Zhao , QEMU Developers , Shannon Zhao On 02/02/2016 01:03 AM, Michael Tokarev wrote: > 01.02.2016 21:01, Peter Maydell wrote: >> On 1 February 2016 at 17:20, Wei Huang wrote: >>> This patch removes float_high field of PL061State, which doesn't seem >>> to be used anywhere. > [] >>> @@ -88,7 +87,6 @@ static const VMStateDescription vmstate_pl061 = { >>> VMSTATE_UINT32(slr, PL061State), >>> VMSTATE_UINT32(den, PL061State), >>> VMSTATE_UINT32(cr, PL061State), >>> - VMSTATE_UINT32(float_high, PL061State), >>> VMSTATE_UINT32_V(amsel, PL061State, 2), >>> VMSTATE_END_OF_LIST() >> >> This would be a migration compatibility break, so at a minimum >> you need to bump the vmstate struct versions. > > Is it worth the effort to remove this field if it causes > compatibility break? Maybe keep it around, it doesn't hurt? It doesn't hurt. So either way is fine. I just happened to find it while reviewing the code. > At the very least, we may rename it to "unused_float_high", > or something, to indicate it is a known-unused? I don't think renaming solves any problem. Either we keep this variable as it is or remove it. > > Thanks, > > /mjt >