From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rkirh-0006ir-H6 for qemu-devel@nongnu.org; Tue, 10 Jan 2012 16:04:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rkirf-00016a-Ql for qemu-devel@nongnu.org; Tue, 10 Jan 2012 16:04:17 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.143]:38234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rkirf-00016U-OA for qemu-devel@nongnu.org; Tue, 10 Jan 2012 16:04:15 -0500 Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jan 2012 16:04:13 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0AL3I0g194320 for ; Tue, 10 Jan 2012 16:03:19 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0AL2uhj017735 for ; Tue, 10 Jan 2012 19:02:57 -0200 Message-ID: <4F0CA778.50000@us.ibm.com> Date: Tue, 10 Jan 2012 15:02:48 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1323784351-25531-1-git-send-email-stefanha@linux.vnet.ibm.com> <1323784351-25531-6-git-send-email-stefanha@linux.vnet.ibm.com> <20120104105911.7e8ca4e4@doriath> <20120105121603.309fe735@doriath> <4F05C332.7010300@redhat.com> <4F05C83C.4090707@us.ibm.com> <20120105182633.01a7490e@doriath> <20120106104529.584151e7@doriath> <4F070E63.8050405@codemonkey.ws> <20120106174253.60a3f08d@doriath> <4F0C8F11.3080602@codemonkey.ws> <20120110185538.3fddb182@doriath> In-Reply-To: <20120110185538.3fddb182@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Stefan Hajnoczi , libvir-list@redhat.com, Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Eric Blake On 01/10/2012 02:55 PM, Luiz Capitulino wrote: > On Tue, 10 Jan 2012 13:18:41 -0600 > Anthony Liguori wrote: > >> On 01/06/2012 01:42 PM, Luiz Capitulino wrote: >>> On Fri, 06 Jan 2012 09:08:19 -0600 >>>> We also need to look at this interface as a public interface whether we >>>> technically committed it to or not. The fact is, an important user is relying >>>> upon so that makes it a supported interface. Even though I absolutely hate it, >>>> this is why we haven't changed the help output even after all of these years. >>>> Not breaking users should be one of our highest priorities. >>> >>> One thing I don't understand: how is libvirt relying on it if it doesn't >>> exist in qemu.git yet? >> >> Because there was a discussion on qemu-devel and we agreed on an interface that >> both sides would implement to. >> >> I expect this to happen more often in the future too. > > For future commands we either, implement it right away or ask libvirt to > wait for the command to be merged, or at least pass initial review. Or commit the schema entry to qapi-schema.json with gen=False. But when this command was first proposed, qapi-schema.json didn't exist in the tree :-) >> But aren't we going to introduce a proper async interface? This is what has me >> confused. > > Yes, I was thinking about new block commands using this API before we get > proper async support... Well let's avoid that problem by doing proper async support before we get new block commands ;-) >>> There's more, because I skipped this review in v3 as I jumped to the >>> "proper async support" discussion... >> >> Well let's do proper async support. As I mentioned, I'd rather take this >> command in as-is, introduce proper async support, and then deprecate a bunch of >> stuff at once. > > Ok, I'm willing to do this as Stefan has agreed on deprecating this as soon as > we get proper async support. Excellent. BTW, you mentioned that you were going to send an RFC for proper async support? Regards, Anthony Liguori >> >>>> What I'd suggest is that we take the command in as-is and we mark it: >>>> >>>> Since: 1.1 >>>> Deprecated: 1.2 >>>> See Also: TBD >>>> >>>> The idea being that we'll introduce new generic async commands in 1.2 and >>>> deprecate this command. We can figure out the removal schedule then too. Since >>>> this command hasn't been around all that long, we can probably have a short >>>> removal schedule. >>> >>> That makes its inclusion even discussable :) A few (very honest) questions: >>> >>> 1. Is it really worth it to have the command for one or two releases? >> >> Yes. The most important consideration IMHO is parallelizing development. We >> want the block layer to evolve to the greatest extent possible independent of >> our other subsystems. If we don't have the right infrastructure in QMP to >> support a block feature, that shouldn't hold up progress in the block layer to >> the greatest extent possible. >> >>> 2. Will we allow other block commands to use this async API? >> >> Depends on how long it takes to do "proper async support". >> >>> 3. Are we going to accept other ad-hoc async APIs until we have a >>> proper one? >> >> Yes. So let's get serious about getting a proper interface in :-) > > ACK > >> >> Regards, >> >> Anthony Liguori >> >