On Tue, 10 Jan 2012 15:02:48 -0600 Anthony Liguori <aliguori@xxxxxxxxxx> wrote: > On 01/10/2012 02:55 PM, Luiz Capitulino wrote: > > On Tue, 10 Jan 2012 13:18:41 -0600 > > Anthony Liguori<anthony@xxxxxxxxxxxxx> 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 > >> > > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list