qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Dor Laor <dlaor@redhat.com>,
	qemu-devel@nongnu.org,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] KVM call minutes April 3
Date: Wed, 4 Apr 2012 05:37:17 -0500	[thread overview]
Message-ID: <CANAOKxuNf9kd1QW172Py1fwB6hnXxmBOnXC-QMGckBuX5HPYWg@mail.gmail.com> (raw)
In-Reply-To: <4F7BFAEB.7070000@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Apr 4, 2012 2:42 AM, "Paolo Bonzini" <pbonzini@redhat.com> wrote:
>
> Il 04/04/2012 03:18, Michael Roth ha scritto:
> > Attacking the IDL/schema side first is the more rationale approach. From
> > there we can potentially generate ASN.1 BER/DER visitors for the
protocol
> > side, or potentially even just vmstate bindings as a start. I've
recently
> > started looking into the latter... it's completely feasible, the only
> > downside is it complicates the IDL due requiring support for a lot of
> > what are very much vmstate-specific items, but it should be possible to
> > do this in a manner where those annotations are self-contained and
> > ignorable if we opted to replace vmstate-style declarations.
>
> We can also keep the current vmstate descriptions, but access fields
> from the automatically-generated visitors instead of struct fields.
> This keeps the IDL simple.

It may be worthwhile as an incremental step though, one nice thing about
automatically generated bindings is that with the QIDL Anthony prototyped a
while back we assume we serialize by default, so changes in annotated
structs automatically trigger changes in the generated bindings unless you
explicitly mark fields as immutable/derivable/etc, which we can tie into
the build or make check to automatically detect and bring attention to
changes in vmstate. This may be worth the effort if we adopt the proposed 4
year migration support cycle for pc-1.0, since that'll continue to rely on
vmstate even after we move on to an IDL and newer protocol.

>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 1807 bytes --]

  reply	other threads:[~2012-04-04 10:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 14:43 [Qemu-devel] KVM call minutes April 3 Markus Armbruster
2012-04-03 20:43 ` Dor Laor
2012-04-04  1:18   ` Michael Roth
2012-04-04  7:40     ` Paolo Bonzini
2012-04-04 10:37       ` Michael Roth [this message]
2012-04-04 10:53         ` Dor Laor
2012-04-04 11:52           ` Anthony Liguori
2012-04-04 12:01             ` Dor Laor
2012-04-04 12:14           ` Michael Roth
2012-04-04 13:21             ` Igor Mammedov
2012-04-04 14:39               ` Michael Roth
2012-04-05 16:16                 ` Avi Kivity
2012-04-04 11:48   ` Anthony Liguori

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=CANAOKxuNf9kd1QW172Py1fwB6hnXxmBOnXC-QMGckBuX5HPYWg@mail.gmail.com \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=armbru@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).