From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdPP4-0005gA-NC for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:52:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdPOz-0003uj-04 for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:52:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdPOy-0003ub-PR for qemu-devel@nongnu.org; Wed, 21 Dec 2011 11:52:24 -0500 Message-ID: <4EF20EC3.4030603@redhat.com> Date: Wed, 21 Dec 2011 17:52:19 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1319735193-4718-1-git-send-email-mdroth@linux.vnet.ibm.com> <1319735193-4718-2-git-send-email-mdroth@linux.vnet.ibm.com> <4EF06D87.9000809@redhat.com> <4EF092A5.3070108@codemonkey.ws> <4EF09C14.9070102@redhat.com> <4EF0F689.7090806@codemonkey.ws> <4EF1D291.8010203@redhat.com> <4EF1F0FE.4060402@codemonkey.ws> <4EF1FDB7.5040306@redhat.com> <4EF20829.50303@codemonkey.ws> In-Reply-To: <4EF20829.50303@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 01/10] qapi: add Visitor interfaces for uint*_t and int*_t List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Juan Quintela , qemu-devel , Michael Roth On 12/21/2011 05:24 PM, Anthony Liguori wrote: > Ok, I get what you're suggesting. You would like to continue to keep > VMStateDescription describing both the QEMUFile format and the fields. I don't "like" to do that, but yes, that's what I'm suggesting. :) You envision having the front-end (state->introspectable state representation) and back-end (state representation->serialization) completely decoupled in the future, with migration filters in the middle if necessary. I actually agree this is as the final direction. For this reason, the first step should be to decouple the front-end and backend and actually have this introspectable state representation. Then you can also break VMStateDescription apart into a front-end and backend part. Mike's patches change the way you write to QEMUFile, so the new code _does_ go in the right direction. However, they fail to provide an introspectable, backend-independent state representation. Let's put it in a few diagrams: where we are now: struct ---> QEMUFile ^ | VMStateDescription what Mike's patches do: struct ---> QEMUFileVisitor ---> QEMUFile ^ | VMStateDescription what I proposed: struct ---> QMPOutputVisitor ---> QObject ^ | VMStateDescription QObject ---> QEMUFile ^ | VMStateDescription where you want to go: struct ---> QMPOutputVisitor ---> QObject ^ | DeviceStateDescription QObject ---> QEMUFileOutputVisitor ---> QEMUFile ^ | VMStateDescription As Mike's patches stand, I'm worried that they would make further steps harder rather than easier. This is because I'm not convinced that the QEMUFileOutputVisitor is actually useful. However, the new code from Mike's patches is very close to the backend-independent representation from the VMStateDescription. So, Mike's patches could be morphed into this pretty easily: struct ---> QMPOutputVisitor ---> QObject ^ | VMStateDescription struct ---> QEMUFile \ ^ \ that's savevm.c, | / unchanged VMStateDescription / This is an intermediate state that lets us do the next steps: - serialize to QEMUFile from a QObject; - reintroduce Mike's QEMUFileOutputVisitor [I don't really see the benefit of this]; - split the DeviceStateDescription and the VMStateDescription; None of these three steps are a prerequisite for introducing a new migration format. > One of the reasons for this split up is because I would like to generate > the first table by IDL and make the second table not dependent on > structure members (so we don't end up with all the hacks we have with > dummy struct fields). That would be a few years away. Let's reason in incremental steps. Paolo