All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Juan Quintela <quintela@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 01/10] qapi: add Visitor interfaces for uint*_t and int*_t
Date: Wed, 21 Dec 2011 13:35:29 +0100	[thread overview]
Message-ID: <4EF1D291.8010203@redhat.com> (raw)
In-Reply-To: <4EF0F689.7090806@codemonkey.ws>

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

  reply	other threads:[~2011-12-21 12:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-27 17:06 [Qemu-devel] [PATCH v2 00/10] do savevm/migration save/load via Visitor interface Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 01/10] qapi: add Visitor interfaces for uint*_t and int*_t Michael Roth
2011-12-20 11:12   ` Paolo Bonzini
2011-12-20 11:43     ` Paolo Bonzini
2011-12-20 12:00       ` Paolo Bonzini
2011-12-20 13:50     ` Anthony Liguori
2011-12-20 14:30       ` Paolo Bonzini
2011-12-20 20:22         ` Michael Roth
2011-12-21 12:29           ` Paolo Bonzini
2011-12-20 20:56         ` Anthony Liguori
2011-12-21 12:35           ` Paolo Bonzini [this message]
2011-12-21 14:45             ` Anthony Liguori
2011-12-21 15:39               ` Paolo Bonzini
2011-12-21 16:24                 ` Anthony Liguori
2011-12-21 16:52                   ` Paolo Bonzini
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 02/10] qapi: add QemuFileOutputVisitor Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 03/10] qapi: add QemuFileInputVisitor Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 04/10] savevm: move QEMUFile interfaces into qemu-file.c Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 05/10] qapi: test cases for QEMUFile input/output visitors Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 06/10] qemu-file: add QEMUFile<->visitor lookup routines Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 07/10] trace: qemu_(put|get)_(byte|buffer) events Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 08/10] trace: add trace statements for visitor interface Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 09/10] qapi: add trace statements to qapi-visit-core.c Michael Roth
2011-10-27 17:06 ` [Qemu-devel] [PATCH v2 10/10] vmstate: use visitors Michael Roth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EF1D291.8010203@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.