Re: [libvirt] [Qemu-devel] QMP: Supporting off tree APIs

On 01/10/2012 02:55 PM, Luiz Capitulino wrote: > On Tue, 10 Jan 2012 13:18:41 -0600 > Anthony Liguori<anthony(a)codemonkey.ws> 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 >> >