[Qemu-devel] QAPI Merge Plans

[Qemu-devel] QAPI Merge Plans

[Anthony Liguori]

Hi,

I've gotten my QAPI branch now functionally complete so I'm ready to 
start working on merging.  I thought I'd send a note about my plans as 
both a heads up and to see if anyone had any suggestions.

My plan is to split everything up into three rounds.  The first round 
will just be core infrastructure--the code generator, the new QMP 
server, the signal infrastructure, etc.  This round will introduce a new 
command line option to expose the new QMP server (still chardev based).

Round two will consist of all of the 0.14 commands.  Some new commands 
are also needed because some of the 0.14 commands are untestable without 
new QMP commands :-/

Finally, round three will include some of the new and potentially 
controversial bits like the new non-chardev based QMP server, default 
session and discovery, qsh tool, etc.

After these three rounds are merged, I'll then work on adding all of the 
new QMP commands to support a full HMP session.

I've tried to put a ton of information on the wiki that hopefully will 
give a good amount of background along with current status.

I expect the first round of patches to be on list this week.

http://wiki.qemu.org/Features/QAPI

Regards,

Anthony Liguori

[Qemu-devel] Re: QAPI Merge Plans

[Luiz Capitulino]

On Sun, 06 Mar 2011 14:54:53 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Hi,
> 
> I've gotten my QAPI branch now functionally complete so I'm ready to 
> start working on merging.  I thought I'd send a note about my plans as 
> both a heads up and to see if anyone had any suggestions.
> 
> My plan is to split everything up into three rounds.  The first round 
> will just be core infrastructure--the code generator, the new QMP 
> server, the signal infrastructure, etc.  This round will introduce a new 
> command line option to expose the new QMP server (still chardev based).

This means current-to-be-replaced infrastructure is still available? I'd
like to avoid having two (public) QMPs if possible, even temporary.

Btw, I've been maintaining a QMP tree but as this is a whole new thing,
I think that this can be directly merged on master as soon as you get the
(whatever needed) ACKs.

> 
> Round two will consist of all of the 0.14 commands.  Some new commands 
> are also needed because some of the 0.14 commands are untestable without 
> new QMP commands :-/
> 
> Finally, round three will include some of the new and potentially 
> controversial bits like the new non-chardev based QMP server, default 
> session and discovery, qsh tool, etc.
> 
> After these three rounds are merged, I'll then work on adding all of the 
> new QMP commands to support a full HMP session.
> 
> I've tried to put a ton of information on the wiki that hopefully will 
> give a good amount of background along with current status.
> 
> I expect the first round of patches to be on list this week.
> 
> http://wiki.qemu.org/Features/QAPI
> 
> Regards,
> 
> Anthony Liguori
> 

[Qemu-devel] Re: QAPI Merge Plans

[Anthony Liguori]

On 03/08/2011 05:18 PM, Luiz Capitulino wrote:
> On Sun, 06 Mar 2011 14:54:53 -0600
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>> Hi,
>>
>> I've gotten my QAPI branch now functionally complete so I'm ready to
>> start working on merging.  I thought I'd send a note about my plans as
>> both a heads up and to see if anyone had any suggestions.
>>
>> My plan is to split everything up into three rounds.  The first round
>> will just be core infrastructure--the code generator, the new QMP
>> server, the signal infrastructure, etc.  This round will introduce a new
>> command line option to expose the new QMP server (still chardev based).
> This means current-to-be-replaced infrastructure is still available?

Yes.

>   I'd
> like to avoid having two (public) QMPs if possible, even temporary.

It's unavoidable unless we're going to try and review and merge a huge 
number of patches at once.  If we do that, nothing's going to get 
reviewed properly and I want to avoid another qdev-style merge and then 
ask for forgiveness afterwards :-)

I'm not hugely opposed to just not merging the -qmp2 flag but I don't 
really see it as a bad thing.  -qmp2 disappears once round two is merged 
and round 2 should be very easy to merge once round 1 is merged.

The command conversion is extremely straight forward minus some of the 
qdev error propagation changes.

Regards,

Anthony Liguori