qemu-devel
[Top][All Lists]
Advanced

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

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


From: Lei Li
Subject: Re: [Qemu-devel] [PATCH 4/6] QAPI: Introduce memchar_read QMP command
Date: Thu, 23 Aug 2012 15:30:28 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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 <address@hidden>
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




reply via email to

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