From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdLOW-00058k-KP for qemu-devel@nongnu.org; Wed, 21 Dec 2011 07:35:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdLOQ-0001Tz-Lr for qemu-devel@nongnu.org; Wed, 21 Dec 2011 07:35:40 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:39403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdLOQ-0001Tl-EN for qemu-devel@nongnu.org; Wed, 21 Dec 2011 07:35:34 -0500 Received: by wgbds1 with SMTP id ds1so12848091wgb.10 for ; Wed, 21 Dec 2011 04:35:33 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4EF1D291.8010203@redhat.com> Date: Wed, 21 Dec 2011 13:35:29 +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> In-Reply-To: <4EF0F689.7090806@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 , Michael Roth , qemu-devel On 12/20/2011 09:56 PM, Anthony Liguori wrote: >> As always, you can implement that in many ways. However, I think the >> point of using Visitors is not to remove QEMUFile. > > Yes, it is. The point of using Visitors is to provide a standard representation of device state. QEMUFile is but one consumer of that representation, along with any other migration filter. > We need something like a migration filter capability where we can > encapsulate this kind of logic such that we can ween VMState away > from these things (and ultimately switch to an IDL compiler). > > We can't do a migration filter until we have something like Michael's > series. Agreed. I'm saying that the QEMUFile serialization should be the first example of a migration filter. Mike's patch add a layer of indirection in the code, but not in the data. We can't do a migration filter until we have device state represented as introspectable data. >> Yes, this is accurate, but I see the goals differently. We should: >> >> (1) First and foremost, provide a backend-independent representation >> of device state so that we can add other backends later. > > And Mike's series does this, no? No. >> (2) Serialize this with QEMUFile, both for backwards-compatibility and >> to ensure that the whole thing works. > > Mike's series also does this, no? It serializes device state directly, without going through a backend-independent representation. It doesn't provide a place in which you can plug a filter. Paolo