Re: [Qemu-devel] [PATCH v4 7/8] BitmapLog: get the information about the parameters

[Eric Blake]

On 07/17/2014 05:21 AM, Sanidhya Kashyap wrote:
> Added the qmp interface to know about the information of the bitmap dump
> process. When the command is executed, one can know about the current epoch
> value in which the process is in, the total iterations value and the current
> frequency value.
> 
> Currently, I do not think that that one needs to modify the other values
> except frequency, so that is why I have not added the generic set-tuning
> interface. If required, I will add it.
> 
> Signed-off-by: Sanidhya Kashyap <address@hidden>
> ---
>  qapi-schema.json | 31 +++++++++++++++++++++++++++++++
>  qmp-commands.hx  | 24 ++++++++++++++++++++++++
>  savevm.c         | 26 ++++++++++++++++++++++++++
>  3 files changed, 81 insertions(+)

Ah, this answers one of my questions in 6/8.  I would reorder the series
and put this right after 3/8 (being able to query initial values is
still useful, whether or not we also add on-the-fly tuning commands).

> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 90977eb..1b09235d 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3487,6 +3487,24 @@
>  { 'command': 'rtc-reset-reinjection' }
>  
>  ##
> +# @BitmapLogStateInfo
> +#
> +# Provides information for the bitmap logging process
> +#
> +# @currepoch: provides the value of the running epoch value

No need to abbreviate.  And given my naming question in 3/8, would this
be better as: current-iteration

> +#
> +# @epochs: provides the information about the actual epoch

and iterations

Wait.  Is this number a constant (the number requested when logging
started, no matter what currepoch is)...[1]


> +#
> +# @frequency: the time difference in milliseconds between each epcoh

s/epcoh/epoch/ (or iteration)

> +#
> +# Since 2.2
> +##
> +{ 'type': 'BitmapLogStateInfo',
> +  'data': { 'currepoch': 'int',
> +            'epochs':    'int',
> +            'frequency': 'int' } }
> +
> +##
>  # @log-dirty-bitmap
>  #
>  # dumps the dirty bitmap to a file by logging the
> @@ -3524,3 +3542,16 @@
>  { 'command': 'log-dirty-bitmap-set-frequency',
>    'data': {'frequency': 'int' } }
>  
> +##
> +# @log-dirty-bitmap-get-tuning

Most query interfaces are in the query- namespace.  Maybe this would be
better as query-log-dirty-bitmap?

> +#
> +# Get the current values of the parameters involved in  bitmap logging 
> process

Accidental double space.

> +#
> +# This command returns the following elements in the form of 
> BitmapLogStateInfo:
> +# - currepoch: current epoch value
> +# - epochs: total epochs for which the bitmap dumping will continue

...[1]or is it the number of iterations remaining (that is,
currepoch+epochs is the original value, and both numbers are changing as
iterations progress)?  Rather than duplicate the parameters in two
places (and with different information, which led to my question about
semantics), it might be nicer to just mention here that the information
is returned as a BitmapLogStateInfo and be done with it (the user can go
look up the documentation of that struct).

> +# - frequently: the current sleep interval between each epoch

s/frequently/frequency/

> +#
> +# Since 2.2
> +##
> +{ 'command': 'log-dirty-bitmap-get-tuning', 'returns': 'BitmapLogStateInfo' }

> +Get the parameters information
> +
> +- "currepoch": the current epoch going on
> +- "epochs" the total number of assigned epochs
> +- "frequency": the sleep interval between each epoch (in milliseconds)
> +
> +Example:
> +
> +-> { "execute": "log-dirty-bitmap-get-tuning" }
> +<- { "return": {
> +            "currepoch": 3
> +            "epochs": 100
> +            "frequency": 100 } }

Invalid JSON.  You are missing two commas.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature