All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface
Date: Mon, 3 Oct 2011 18:51:41 +0200	[thread overview]
Message-ID: <20111003165140.GK20141@redhat.com> (raw)
In-Reply-To: <4E89DD2E.700@codemonkey.ws>

On Mon, Oct 03, 2011 at 11:05:02AM -0500, Anthony Liguori wrote:
> On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote:
> >>BTW, putting this info properly into migration stats would probably
> >>be pretty useful.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Problem is adding anything to monitor makes me worry
> >about future compatibility so much I usually just give up.
> >IMO we really need a namespace for in-development experimental
> >commands, like "unsupported-XXX", this would belong.
> 
> Or just make all of QMP unsupported across any given version.  I'm
> not kidding about that actually.
> 
> If we document what the protocol is for any given version, then a
> layer like libvirt can deal with providing a consistent interface.

Once distros ship qemu, people will use it. Once they use it
in some way for long, it becomes the supposted interface.
No one reads documentation, obviously :) - do you expect
people to re-read qemu documentation *with every release*?

> 
> I often wonder who we're trying to preserve compatibility for.  Part
> of libvirt's mission statement is providing a stable API so why not
> leverage that mission and get us out of the compatibility business.
> 
> Regards,
> 
> Anthony Liguori

you can't force everyone to use libvirt.
Part of QMP mission statement was a stable interface.
If it's not that I don't know what it's for.

-- 
MST

  parent reply	other threads:[~2011-10-03 16:51 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-19 14:41 [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface Michael Roth
2011-09-19 14:41 ` [Qemu-devel] [RFC 1/8] qapi: add Visitor interfaces for uint*_t and int*_t Michael Roth
2011-09-19 14:41 ` [Qemu-devel] [RFC 2/8] qapi: add QemuFileOutputVisitor Michael Roth
2011-09-19 14:41 ` [Qemu-devel] [RFC 3/8] qapi: add QemuFileInputVisitor Michael Roth
2011-10-24 23:59   ` Chris Krumme
2011-09-19 14:41 ` [Qemu-devel] [RFC 4/8] savevm: move QEMUFile interfaces into qemu-file.c Michael Roth
2011-09-24  7:23   ` Blue Swirl
2011-09-19 14:41 ` [Qemu-devel] [RFC 5/8] qapi: test cases for QEMUFile input/output visitors Michael Roth
2011-09-19 14:41 ` [Qemu-devel] [RFC 6/8] savevm: add QEMUFile->visitor lookup routines Michael Roth
2011-09-19 14:41 ` [Qemu-devel] [RFC 7/8] cutil: add strocat(), to concat a string to an offset in another Michael Roth
2011-09-20 10:43   ` Paolo Bonzini
2011-09-19 14:41 ` [Qemu-devel] [RFC 8/8] slirp: convert save/load function to visitor interface Michael Roth
2011-09-30 13:39   ` Anthony Liguori
2011-09-30 14:08     ` Michael Roth
2011-10-02 20:21 ` [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface Stefan Berger
2011-10-02 21:08   ` Michael S. Tsirkin
2011-10-03 12:55     ` Anthony Liguori
2011-10-03 13:10       ` Stefan Berger
2011-10-03 13:18         ` Anthony Liguori
2011-10-03 13:30           ` Michael S. Tsirkin
2011-10-03 13:48             ` Anthony Liguori
2011-10-03 14:18               ` Michael S. Tsirkin
2011-10-03 14:56                 ` Anthony Liguori
2011-10-03 15:42                   ` Michael S. Tsirkin
2011-10-03 13:38       ` Michael S. Tsirkin
2011-10-03 13:51         ` Anthony Liguori
2011-10-03 14:41           ` Michael S. Tsirkin
2011-10-03 15:00             ` Anthony Liguori
2011-10-03 15:45               ` Michael S. Tsirkin
2011-10-03 16:05                 ` Anthony Liguori
2011-10-03 16:24                   ` Daniel P. Berrange
2011-10-03 16:51                   ` Michael S. Tsirkin [this message]
2011-10-05 11:28               ` Michael S. Tsirkin
2011-10-05 12:46                 ` Anthony Liguori
2011-10-03  6:46 ` Michael S. Tsirkin
2011-10-03 12:51   ` Anthony Liguori
2011-10-03 13:24     ` Michael S. Tsirkin
2011-10-03 13:43       ` Anthony Liguori
2011-10-03 14:11         ` Michael S. Tsirkin
2011-10-03 14:42           ` Anthony Liguori
2011-10-03 15:29             ` Michael S. Tsirkin
2011-10-03 15:44               ` Anthony Liguori
2011-10-03 15:58                 ` Michael S. Tsirkin
2011-10-03 16:02                   ` Anthony Liguori
2011-10-03 14:15         ` Michael S. Tsirkin
2011-10-03 14:55           ` Anthony Liguori
2011-10-03 15:41             ` Michael S. Tsirkin
2011-10-05  2:05         ` Stefan Berger
2011-10-05 12:54           ` Anthony Liguori
2011-10-05 19:06             ` Michael S. Tsirkin

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=20111003165140.GK20141@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.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.