Re: [Qemu-devel] [PATCH 4/6] QAPI: Introduce memchar_read QMP command

[Lei Li <lilei@linux.vnet.ibm.com>]

On 08/23/2012 01:46 PM, Eric Blake wrote:
> On 08/22/2012 11:14 PM, Lei Li wrote:
>> Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com>
> Again, subject line should use '-' not '_' for QMP.
>
>> ---
>>   hmp-commands.hx  |   16 ++++++++++++++++
>>   hmp.c            |   15 +++++++++++++++
>>   hmp.h            |    1 +
>>   qapi-schema.json |   23 +++++++++++++++++++++++
>>   qemu-char.c      |   32 ++++++++++++++++++++++++++++++++
>>   qmp-commands.hx  |   31 +++++++++++++++++++++++++++++++
>>   6 files changed, 118 insertions(+), 0 deletions(-)
>>
>> diff --git a/hmp-commands.hx b/hmp-commands.hx
>> index 829aea1..9f61633 100644
>> --- a/hmp-commands.hx
>> +++ b/hmp-commands.hx
>> @@ -813,6 +813,22 @@ to memchr char device with size @var{size}.
>>   ETEXI
>>   
>>       {
>> +        .name       = "memchar-read",
> while the HMP command should use '_' not '-'.
>
>> +++ b/qapi-schema.json
>> @@ -264,6 +264,29 @@
>>              '*format': 'DataFormat'} }
>>   
>>   ##
>> +# @memchar-read:
>> +#
>> +# Provide read interface for memchardev. Read from memchar
>> +# char device and return the data.
>> +#
>> +# @chardev: the name of the  memchar char device.
> Why two spaces?
>
>> +#
>> +# @size: the size to write in bytes.
> s/write/read/
>
>> +#
>> +# @format: #optional the format of the data want to read from
>> +#          memchardev, by default is 'utf8'.
>> +#
>> +# Returns: The data read from memchar as string.
>> +#          If @chardev is not a valid memchr device, DeviceNotFound
>> +#          If an I/O error occurs while reading, IOError
>> +#
>> +# Since: 1.2
> 1.3
>
>> +##
>> +{ 'command': 'memchar-read',
>> +  'data': {'chardev': 'str', 'size': 'int', '*format': 'DataFormat'},
>> +  'returns': 'str' }
> While writing can default to UTF-8, I'm worried about reading - does
> encoding in UTF-8 allow transmission of NUL bytes through JSON, or do
> you have to use base64 to allow full binary data through?  What happens
> if the data read includes a NUL byte that can't be encoded back into the
> requested DataFormat?

Yes, you are right. g_base64_encode did not support NULL bytes encoding, so
encoding in UTF-8 should not allow transmission of NULL bytes through JSON.
Thanks for pointing this out!


-- 
Lei