On Tue, May 01, 2012 at 04:31:44PM +0100, Stefan Hajnoczi wrote:
> From: Anthony Liguori <aligu...@us.ibm.com>
>
> Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
> Signed-off-by: Stefan Hajnoczi <stefa...@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.
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
