On Tue, Apr 24, 2012 at 4:17 PM, Eric Blake <ebl...@redhat.com> wrote:
> On 04/24/2012 07:53 AM, Stefan Hajnoczi wrote:
>> Allow streaming operations to be started with an initial speed limit.
>> This eliminates the window of time between starting streaming and
>> issuing block-job-set-speed.  Users should use the new optional 'speed'
>> parameter instead so that speed limits are in effect immediately when
>> the job starts.
>>
>
>> +++ b/hmp-commands.hx
>> @@ -71,8 +71,8 @@ ETEXI
>>
>>      {
>>          .name       = "block_stream",
>> -        .args_type  = "device:B,base:s?",
>> -        .params     = "device [base]",
>> +        .args_type  = "device:B,speed:o?,base:s?",
>
> Am I remembering correctly that the :o type lets me pass in suffixes,
> including 'b' to force bytes, but defaults to 'M' if I don't pass a
> suffix?  Should we be documenting the default unit and the ability to
> scale as part of the command help (see migrate_set_speed for a similar
> command that documents the scaling)?

Yes, it supports suffixes.  The HMP documentation for these commands
does not include details about the parameters, so I didn't document it
- management tools should be using QMP and HMP is mainly for
debugging/ad-hoc testing.

>> +        .params     = "device [speed] [base]",
>
> By having two optional arguments in HMP, can I write 'block_stream
> device base' and have things work, or am I now forced to provide a speed
> if I want a base?  If the latter, wouldn't this look better as:
>
> .params = "device [speed [base]]",
>
> and if so, how many other HMP commands suffer from the same
> documentation flaw?

You are right.  The .params I gave are incorrect since you must give
'speed' if you want to give 'base'.

Stefan

Reply via email to