Re: [Qemu-devel] [V5 Patch 3/4]Qemu: Command "block_set" for dynamic block params change

[Stefan Hajnoczi]

On Wed, Jul 27, 2011 at 1:58 PM, Anthony Liguori <address@hidden> wrote:
>> Index: qemu/hmp-commands.hx
>> ===================================================================
>> --- qemu.orig/hmp-commands.hx
>> +++ qemu/hmp-commands.hx
>> @@ -70,6 +70,20 @@ but should be used with extreme caution.
>>  resizes image files, it can not resize block devices like LVM volumes.
>>  ETEXI
>>
>> +    {
>> +        .name       = "block_set",
>> +        .args_type  = "device:B,device:O",
>> +        .params     = "device [prop=value][,...]",
>> +        .help       = "Change block device parameters
>> [hostcache=on/off]",
>> +        .user_print = monitor_user_noop,
>> +        .mhandler.cmd_new = do_block_set,
>> +    },
>> +STEXI
>> address@hidden block_set @var{config}
>> address@hidden block_set
>> +Change block device parameters (eg: hostcache=on/off) while guest is
>> running.
>> +ETEXI
>> +
>
> block_set_hostcache() please.
>
> Multiplexing commands is generally a bad idea.  It weakens typing.  In the
> absence of a generic way to set block device properties, implementing
> properties as generic in the QMP layer seems like a bad idea to me.

The idea behind block_set was to have a unified interface for changing
block device parameters at runtime.  This prevents us from reinventing
new commands from scratch.  For example, block I/O throttling is
already queued up to add run-time parameters.

Without a unified command we have a bulkier QMP/HMP interface,
duplicated code, and possibly inconsistencies in syntax between the
commands.  Isn't the best way to avoid these problems a unified
interface?

I understand the lack of type safety concern but in this case we
already have to manually pull parsed arguments (i.e. cast to specific
types and deal with invalid input).  To me this is a reason *for*
using a unified interface like block_set.

Stefan