From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RknCO-0001cM-9c for qemu-devel@nongnu.org; Tue, 10 Jan 2012 20:41:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RknCM-0004Yy-Se for qemu-devel@nongnu.org; Tue, 10 Jan 2012 20:41:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RknCM-0004Yu-Je for qemu-devel@nongnu.org; Tue, 10 Jan 2012 20:41:54 -0500 Date: Tue, 10 Jan 2012 23:41:41 -0200 From: Luiz Capitulino Message-ID: <20120110234141.086cc463@doriath> In-Reply-To: <4F0CA778.50000@us.ibm.com> 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> <4F0CA778.50000@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , libvir-list@redhat.com, Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Eric Blake On Tue, 10 Jan 2012 15:02:48 -0600 Anthony Liguori wrote: > 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? It's just a few proposals for the high-level API (ie. no patches), I can send it tomorrow. > > 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 > >> > > >