qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command


From: Luiz Capitulino
Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command
Date: Tue, 23 Jun 2009 13:59:58 -0300

On Tue, 23 Jun 2009 08:59:42 -0500
Anthony Liguori <address@hidden> wrote:

> Avi Kivity wrote:
> > On 06/23/2009 07:29 AM, Luiz Capitulino wrote:
> >>       else if (actual == 0)
> >> -        monitor_printf(mon, "Ballooning not activated in VM\n");
> >> +        monitor_printf_err(mon, "Ballooning not activated in VM\n");
> >>       else
> >> -        monitor_printf(mon, "balloon: actual=%d\n", (int)(actual>>  
> >> 20));
> >> +        monitor_printf_data(mon, "balloon: actual=%d\n", 
> >> (int)(actual>>  20));
> >>   }
> >>    
> >
> > Control mode should always use bytes and seconds (and this should be 
> > described in the spec).  You avoid rounding, and more importantly, 
> > ambiguity and a source of unit conversion errors.
> 
> I'd actually like to see a lot more structure in this sort of output.  
> For instance:
> 
> monitor_printf_list(mon, "balloon",
>                                "actual", MON_TIME, actual,
>                                NULL);
> 
> How this gets output can then be conditional on control mode vs. human 
> mode.  In human mode, we can use human-friendly units like MBs.  In 
> control mode, we would always use bytes.

 For me, this is one of the hardest aspects of the project.

 It is more general than unit conversion, the problem is: how should
commands output (specially multline) look like?

 I have talked with Eduardo about this, and I have chosen the simplest
approach, which is prefixing commands output by '='. That is, the
protocol doesn't change commands output, just adds prefixes.

 This approach has the advantage of making the protocol merge very
easy and I believe it will be less painful to maintain as well.

 On the other hand, the format of most commands are not good/meant
to be parsed, this gives the possibility of:

> > We also need a way to discover that the command is available:
> 
> I think we want to version each command too.

 making it quite complicated. :)

 If we go this way (of defining an output for each command or even
defining a version for each command) I fear we will take forever
to get in agreement and merge the whole series.

 Another related question is: should we port 100% of the command
set up front or can we merge small sets, defining a new version of
the protocol each time?

 What I would like to do for QMP V1 is:

1. Keep what this series is doing, that is, keep commands output
unchanged and only add prefixes (unit conversion is ok though)

2. Define a set of commands to be part of V1, and port them

 We can try to port the whole set as fast as we can (say, until
V3). Right after that, we could start improving commands output.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]