From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4deg-0004h4-Eu for qemu-devel@nongnu.org; Mon, 05 Mar 2012 14:33:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4de3-0004xi-Nv for qemu-devel@nongnu.org; Mon, 05 Mar 2012 14:33:05 -0500 Received: from mail-pz0-f46.google.com ([209.85.210.46]:52791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4de3-0004vf-Hi for qemu-devel@nongnu.org; Mon, 05 Mar 2012 14:32:31 -0500 Received: by dajr28 with SMTP id r28so6821311daj.33 for ; Mon, 05 Mar 2012 11:32:17 -0800 (PST) Message-ID: <4F5514BC.5020408@codemonkey.ws> Date: Mon, 05 Mar 2012 13:32:12 -0600 From: Anthony Liguori 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> <4F55047D.3070006@redhat.com> In-Reply-To: <4F55047D.3070006@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: lcapitulino@redhat.com, Alon Levy , qemu-devel@nongnu.org, kraxel@redhat.com On 03/05/2012 12:22 PM, Avi Kivity wrote: > 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 This is our only short term options for this specific circumstance. > 2. introduce capabilities that say "screendump is fixed wrt bug so-and-so" We don't have such a mechanism and I generally would prefer to avoid it. There's a certain shame in introducing new commands that hopefully will cause us to be more careful in the future. > 3. fix it and backport the fix to a stable release This is only not practical because it requires such an infrastructure change. > 4. ignore the broken command and hope 5. just tell clients to rely on version information and ignore the existence of downstreams This is really mostly a downstream problem, not an upstream problem. Version numbers can be reliable here for upstream. This is the approach that would be typically taken for a C library. The flip side is that this is also while we end up with autotools and a bunch of compile time tests to determine what broken functions exist. Regards, Anthony Liguori > > My preference is 3->2->1->4, or we'll end up with screendump65535 soon. >