qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: aliguori@us.ibm.com, Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, lcapitulino@redhat.com, bsd@redhat.com,
	y-goto@jp.fujitsu.com, afaerber@suse.de,
	Wanlong Gao <gaowanlong@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -numa option
Date: Tue, 16 Jul 2013 08:24:26 +0200	[thread overview]
Message-ID: <51E4E71A.8040500@redhat.com> (raw)
In-Reply-To: <51E46AB0.5090708@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 15/07/2013 23:33, Eric Blake ha scritto:
>>>>> Newer libvirt can be taught to append 'M' when it detects
>>>>> it is talking to newer qemu.  While you have a point that
>>>>> it is annoying to force users to upgrade to a newer libvirt
>>>>> merely because they upgraded qemu, the libvirt point of
>>>>> view is that the following are supported:
>>>>> 
>>>>> old libvirt -> old qemu new libvirt -> old qemu new libvirt
>>>>> -> new qemu
>>>>> 
>>>>> but that this combination is always best effort and not
>>>>> required to work:
>>>>> 
>>>>> old libvirt -> new qemu
>>> 
>>> I don't think this is the case, unless you're talking of *very*
>>> old libvirt (e.g. pre-QMP).
> As a counter-example, I can recall a case where a qemu release that
> used just two digits (was that 1.2?) broke operation under older
> libvirt that assumed versions would always be three digits; but it
> definitely occurred after 0.15.x which is the point at which
> libvirt started favoring QMP.  That is, we had a case in Fedora
> where if you upgraded qemu, you HAD to also update libvirt to be
> able to keep your guests running.

Right, I remember that now.  So, better: "we have some interfaces
which are considered API, and old libvirt -> new QEMU should not break
for things that use those interfaces".  QMP and the command line are
definitely one.

The case you mentioned was about -help, if I remember correctly, which
was indeed quite brittle (like HMP).

> But yes, the goal of having command line compatibility, so that
> any application using the same command line it always uses will get
> the same guest, regardless of a qemu upgrade in the meantime,
> should be our default mode of operation, even if newer apps should
> prefer newer (better) command line interfaces.

Yes, the command line *is* part of the API.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5OcaAAoJEBvWZb6bTYbyGQgQAJVrX6z8/0hozhjAz81G7tuX
cVmnC5cw+TgfYspf73yoBLBYZPUY/Ydb7WiabKrSfweMFX848WVhQr7rkwp0DVKQ
X0WSbEKrVIGRMCjtvEMkzw1fmXintPLsaoxaLqYZs2MFgEsEP1eEG2MT/2JwpFd/
iDkqVmQ9fPxCEm8beoJXN8HV4Mwz5YY5E04tSqCktJzPh9+sGwB4cPy7PPiPjvHK
I8nIdLHtOqFs4SwX1ic6HEZbeBE71swxr5QKhSg3/v6MzjZbK9/IU0RBcY69ftek
3fRJV8/hs8mHhfT7LsvB7XCNOxYq8jD1Bzy4oMJ/3LcAOyTLt1QJzFW4yaRSNGBK
6V/pDSWlghefulZu/aZASMh/IyxuCJRJ0uMVUEi20FeaIs96Bq5QBEInN/1JIYdH
Qkek7C6dTrP1EdfbZFRa8+RzYEIDL0XmJFce8oicPZLGbhr/Jg1tZAkcUGr9gaeh
z9bOTgAI98z29ZSHm4Bb3rb1WWSJY7BBRAgIDDxZuf34wuVUGWEvJOHRkB2iRa87
d6howw9eqWogVNNYHKYoTQCxEaTe7/PB0wXdWX5+AAZ29C0ETPZFOBYVwh9QLuCD
V9WxGutqlXohbTgOk8rERHcUMJLlNblJg/i0tOMDU2Me4Uv+nW8UawEWUJClZiZS
5emSnaCr7UwPS9qUz1n1
=LQs8
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-07-16  6:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04  9:53 [Qemu-devel] [PATCH V4 00/10] Add support for binding guest numa nodes to host numa nodes Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -numa option Wanlong Gao
2013-07-05 18:41   ` Eduardo Habkost
2013-07-08 19:02     ` Eric Blake
2013-07-08 19:25       ` Eduardo Habkost
2013-07-08 19:25       ` Anthony Liguori
2013-07-09  3:28         ` Wanlong Gao
2013-07-09  3:34           ` Eric Blake
2013-07-14 11:34       ` Paolo Bonzini
2013-07-15 21:33         ` Eric Blake
2013-07-16  6:24           ` Paolo Bonzini [this message]
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 02/10] NUMA: Add numa_info structure to contain numa nodes info Wanlong Gao
2013-07-05 19:32   ` Eduardo Habkost
2013-07-05 20:09     ` Andreas Färber
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 03/10] NUMA: Add Linux libnuma detection Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 04/10] NUMA: parse guest numa nodes memory policy Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 05/10] NUMA: handle Error in cpus, mpol and hostnode parser Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 06/10] NUMA: split out the common range parser Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 07/10] NUMA: set guest numa nodes memory policy Wanlong Gao
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 08/10] NUMA: add qmp command set-mpol to set memory policy for NUMA node Wanlong Gao
2013-07-08 18:25   ` Luiz Capitulino
2013-07-08 18:34     ` Luiz Capitulino
2013-07-08 18:50       ` Andreas Färber
2013-07-08 19:03         ` Luiz Capitulino
2013-07-15 11:18     ` Wanlong Gao
2013-07-08 19:16   ` Eric Blake
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 09/10] NUMA: add hmp command set-mpol Wanlong Gao
2013-07-08 18:32   ` Luiz Capitulino
2013-07-04  9:53 ` [Qemu-devel] [PATCH V4 10/10] NUMA: show host memory policy info in info numa command Wanlong Gao
2013-07-05 18:49   ` Eduardo Habkost
2013-07-08 18:36   ` Luiz Capitulino
2013-07-04 19:49 ` [Qemu-devel] [PATCH V4 00/10] Add support for binding guest numa nodes to host numa nodes Paolo Bonzini
2013-07-04 21:15   ` Laszlo Ersek
2013-07-05  0:55     ` Wanlong Gao
2013-07-05  0:54   ` Wanlong Gao
2013-07-05 19:18 ` Eduardo Habkost
2013-07-11 10:32 ` Peter Huang(Peng)
2013-07-11 13:10   ` Eduardo Habkost

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=51E4E71A.8040500@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=bsd@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=gaowanlong@cn.fujitsu.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=y-goto@jp.fujitsu.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 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).