Patchwork [RFC,2/5] block: add new command line parameter that and protocol description

login
register
mail settings
Submitter Stefan Hajnoczi
Date May 1, 2012, 3:31 p.m.
Message ID <1335886307-27586-3-git-send-email-stefanha@linux.vnet.ibm.com>
Download mbox | patch
Permalink /patch/156141/
State New
Headers show

Comments

Stefan Hajnoczi - May 1, 2012, 3:31 p.m.
From: Anthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
---
 qemu-options.hx |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
Daniel P. Berrange - May 2, 2012, 8:58 a.m.
On Tue, May 01, 2012 at 04:31:44PM +0100, Stefan Hajnoczi wrote:
> From: Anthony Liguori <aliguori@us.ibm.com>
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> ---
>  qemu-options.hx |   42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index a169792..ccf4d1d 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2724,6 +2724,48 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log,
>      "-qtest-log LOG  specify tracing options\n",
>      QEMU_ARCH_ALL)
>  
> +DEF("open-hook-fd", HAS_ARG, QEMU_OPTION_open_hook_fd,
> +    "-open-hook-fd <fd>\n"
> +    "                delegate opens to external process using <fd>\n", QEMU_ARCH_ALL)
> +STEXI
> +@item -open-hook-fd @var{fd}
> +@findex -open-hook-fd
> +Delegates open()s to an external process using @var<fd> to communicate commands.
> +@var<fd> should be an open Unix Domain socket pipe that file descriptors can be
> +received from.  The protocol the socket uses is a simple request/response initiated
> +by the client.  All integers are in host byte order.  It is assumed that this protocol
> +is only ever used on the same physical machine.  It is currently defined as:
> +
> +u32 message_size
> +u32 command
> +u8  payload[message_size - 8]
> +
> +The contents of payload depend on command.  Currently the following commands are
> +defined:
> +
> +1. QEMU_OPEN (1)
> +
> +The full message will be:
> +
> +u32 message_size
> +u32 command = 1
> +u32 flags (O_ flags defined by libc)
> +u32 mode (mode_t flags as defined by libc)
> +u16 filename_len;
> +u8  filename[filename_len]
> +
> +The server will then respond with:
> +
> +u32 message_size
> +u32 command = 1
> +s32 result

If we're going for a binary protocol, then I'd like to see it defined
based on the XDR specification, so we can auto-generate our data
marshallers/demarshallers using existing tools / libraries and not
have to write something custom by hand. Your spec here is close enough
that it would not be significant work. The changes would be

 - Everything is always big-endian
 - Each field has 4-byte alignment
 - Strings would have a u32 length, and the payload padded with NUL
   to the 4 byte boundary

Daniel.
Daniel P. Berrange - May 2, 2012, 9:03 a.m.
On Tue, May 01, 2012 at 04:31:44PM +0100, Stefan Hajnoczi wrote:
> From: Anthony Liguori <aliguori@us.ibm.com>
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> ---
>  qemu-options.hx |   42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index a169792..ccf4d1d 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2724,6 +2724,48 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log,
>      "-qtest-log LOG  specify tracing options\n",
>      QEMU_ARCH_ALL)
>  
> +DEF("open-hook-fd", HAS_ARG, QEMU_OPTION_open_hook_fd,
> +    "-open-hook-fd <fd>\n"
> +    "                delegate opens to external process using <fd>\n", QEMU_ARCH_ALL)
> +STEXI
> +@item -open-hook-fd @var{fd}
> +@findex -open-hook-fd
> +Delegates open()s to an external process using @var<fd> to communicate commands.
> +@var<fd> should be an open Unix Domain socket pipe that file descriptors can be
> +received from.  The protocol the socket uses is a simple request/response initiated
> +by the client.  All integers are in host byte order.  It is assumed that this protocol
> +is only ever used on the same physical machine.  It is currently defined as:
> +
> +u32 message_size
> +u32 command
> +u8  payload[message_size - 8]
> +
> +The contents of payload depend on command.  Currently the following commands are
> +defined:
> +
> +1. QEMU_OPEN (1)
> +
> +The full message will be:
> +
> +u32 message_size
> +u32 command = 1
> +u32 flags (O_ flags defined by libc)
> +u32 mode (mode_t flags as defined by libc)
> +u16 filename_len;
> +u8  filename[filename_len]

I think this should include the ID of the backend of the drive wanting
this file opened, so you can reliably match up to the -drive that mgmt
configured at startup. ie not have to search through every single
device in the guest & all their backing files to find if there is a
match.

Regards,
Daniel

Patch

diff --git a/qemu-options.hx b/qemu-options.hx
index a169792..ccf4d1d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2724,6 +2724,48 @@  DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log,
     "-qtest-log LOG  specify tracing options\n",
     QEMU_ARCH_ALL)
 
+DEF("open-hook-fd", HAS_ARG, QEMU_OPTION_open_hook_fd,
+    "-open-hook-fd <fd>\n"
+    "                delegate opens to external process using <fd>\n", QEMU_ARCH_ALL)
+STEXI
+@item -open-hook-fd @var{fd}
+@findex -open-hook-fd
+Delegates open()s to an external process using @var<fd> to communicate commands.
+@var<fd> should be an open Unix Domain socket pipe that file descriptors can be
+received from.  The protocol the socket uses is a simple request/response initiated
+by the client.  All integers are in host byte order.  It is assumed that this protocol
+is only ever used on the same physical machine.  It is currently defined as:
+
+u32 message_size
+u32 command
+u8  payload[message_size - 8]
+
+The contents of payload depend on command.  Currently the following commands are
+defined:
+
+1. QEMU_OPEN (1)
+
+The full message will be:
+
+u32 message_size
+u32 command = 1
+u32 flags (O_ flags defined by libc)
+u32 mode (mode_t flags as defined by libc)
+u16 filename_len;
+u8  filename[filename_len]
+
+The server will then respond with:
+
+u32 message_size
+u32 command = 1
+s32 result
+
+If result is < 0, the value will be negated errno value as defined in errno.h.  If
+result is equal to 0, then there will also be a file descriptor available via SCM_RIGHTS
+in the extended sendmsg data.
+
+ETEXI
+
 HXCOMM This is the last statement. Insert new options before this line!
 STEXI
 @end table