From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4cYm-0000Pa-RC for qemu-devel@nongnu.org; Mon, 05 Mar 2012 13:23:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4cYl-0004wE-5A for qemu-devel@nongnu.org; Mon, 05 Mar 2012 13:23:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4cYk-0004vw-Sp for qemu-devel@nongnu.org; Mon, 05 Mar 2012 13:22:59 -0500 Message-ID: <4F55047D.3070006@redhat.com> Date: Mon, 05 Mar 2012 20:22:53 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1330956981-5001-1-git-send-email-alevy@redhat.com> <4F54CEA2.10808@codemonkey.ws> <4F54F5F8.70105@redhat.com> <4F54F76B.70403@codemonkey.ws> <4F54F7EA.2010705@redhat.com> <4F5502F7.9000701@codemonkey.ws> In-Reply-To: <4F5502F7.9000701@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Alon Levy , kraxel@redhat.com, lcapitulino@redhat.com On 03/05/2012 08:16 PM, Anthony Liguori wrote: > >> >>> We're pretty close to being there. Luiz, about how long do you >>> think before we get there? >> >> It's a pity to add new commands along the way. > > It's more complicated than this unfortunately. > > A client needs to be able to determine whether the 'screendump' > command works as expected. Unfortunately, when QXL was introduced, > 'screendump' became broken across multiple releases. > > screendump is the right interface, but since it was broken in multiple > releases, we need another command for a client to determine that it's > not broken. In the short term, screendump_async is that. After QAPI, > it will probably be a screendump2. > > I don't mind introducing short term commands and then deprecating it > particularly when they are marked as such. Zooming out from screendump, there are several ways to deal with broken commands: 1. introduce new commands 2. introduce capabilities that say "screendump is fixed wrt bug so-and-so" 3. fix it and backport the fix to a stable release 4. ignore the broken command and hope My preference is 3->2->1->4, or we'll end up with screendump65535 soon. -- error compiling committee.c: too many arguments to function