From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAl0z-0002az-3r for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:05:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAl0r-0005ze-64 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:05:12 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:56250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAl0q-0005vg-Rf for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:05:05 -0400 Received: by mail-iy0-f173.google.com with SMTP id f6so6450461iag.4 for ; Mon, 03 Oct 2011 09:05:04 -0700 (PDT) Message-ID: <4E89DD2E.700@codemonkey.ws> Date: Mon, 03 Oct 2011 11:05:02 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <4E88C7DB.9090105@linux.vnet.ibm.com> <20111002210802.GC8072@redhat.com> <4E89B0D4.3090203@us.ibm.com> <20111003133802.GD18920@redhat.com> <4E89BDCE.2010502@codemonkey.ws> <20111003144109.GE19689@redhat.com> <4E89CE20.6050706@codemonkey.ws> <20111003154554.GE20141@redhat.com> In-Reply-To: <20111003154554.GE20141@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Stefan Berger , Michael Roth , qemu-devel@nongnu.org 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. 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 >