From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXCG8-00053P-6I for qemu-devel@nongnu.org; Mon, 07 Apr 2014 12:19:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXCG1-0001wl-U3 for qemu-devel@nongnu.org; Mon, 07 Apr 2014 12:18:56 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43157 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXCG1-0001wb-Is for qemu-devel@nongnu.org; Mon, 07 Apr 2014 12:18:49 -0400 Message-ID: <5342CFE8.4010703@suse.de> Date: Mon, 07 Apr 2014 18:18:48 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1396840915-10384-1-git-send-email-quintela@redhat.com> <20140407093543.GI2400@work-vm> <87d2gtfoht.fsf@elfo.mitica> In-Reply-To: <87d2gtfoht.fsf@elfo.mitica> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for 2.1 00/97] VMState simplification (massive) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org Am 07.04.2014 12:00, schrieb Juan Quintela: > "Dr. David Alan Gilbert" wrote: >> * Juan Quintela (quintela@redhat.com) wrote: >>> Hi >>> >>> Look at the diffstat. Almost all the additions are at >>> test-vmstate.c. That is the reason why it is called a simplification. >>> >>> What this series does: >>> - peter removal of version_minimum_id_old field when not needed (Pete= r) >>> - cleanup: based on the previous one, I removed all the unneeded >>> the uses on the tree. This should make your compiles >>> a couple of nanoseconds faster. >>> - once there, fixed the indentation of the .fields line, to a canonic= al >>> .fields =3D (VMStateField[]) >>> - mst simplifications for vmstate engine >>> >>> And now, the big cleanup. >>> - Patches only do one thing, to make easy the review. >>> >>> - Added test for all VMSTATE_FOO() definitions >>> (well, I am lying, VMSTATE_STRUCT* are still missing, will come soo= n) >>> - We had two ways to make a field optional >>> VMSTATE_INT64_V(field, state, version) >>> and >>> VMSTATE_INT64_TEST(field, state, test) >>> >>> We can do the version one with one test like: >>> >>> static inline bool vmstate_5_plus(void *opaque, int version_id) >>> { >>> return version_id >=3D 5; >>> } >>> >>> and then change: >>> VMSTATE_INT64_V(field, state, 5); >>> >>> into >>> VMSTATE_INT64_TEST(field, state, vmstate_5_plus); >> >> I'm not sure if I like this; while I'm OK with the idea of changing th= e >> implementation of VMSTATE_INT64_V to use that function trick internall= y, >> it seems like we're discouraging providing easy to parse/record versio= nining >> info out of the tree. >=20 > That information is not exported Today. And if we want to export them, > export v =3D 5 or test =3D=3D vmstat_5_plus is exactly the same dificul= ty. That's not quite true. My code can easily compare an integer field in VMStateDescription, but for any .test function callback I am in the blind: Without executing the test on a specific set of data, I cannot reason whether incoming data will be compatible with the VMSD. > The information is still there, what has changed is the removal of one > mechanism. >=20 > #define VMSTATE_UINT64_V(field, state, X) \ > VMSTATE_UINT64_TEST(field, state, vmstate_##X##_plus) If these were a fixed set of global test functions, it could work, by special-casing function pointer comparisons. > The same that we could do for maintaining the macro, we can do to expor= t > the information to whatever format we want. I just wanted to remove on= e > of the mechanism (the less powerful one). On another matter, I still haven't heard from you on my QOM VMState simplification series from last July: https://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg01072.html If we fix the NVEC issue I discovered in February and add qtests for the remaining optional devices to assure there are no further dc->vmsd overriding devices, would that approach be acceptable to you? Or do you have a better suggestion? Thanks, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg