qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/8] guest agent: add guest-pipe-open


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 4/8] guest agent: add guest-pipe-open
Date: Tue, 03 Feb 2015 14:57:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 12/31/2014 06:06 AM, Denis V. Lunev wrote:
> From: Simon Zolin <address@hidden>
> 
> Creates a FIFO pair that can be used with existing file read/write
> interfaces to communicate with processes spawned via the forthcoming
> guest-file-exec interface.
> 
> Signed-off-by: Simon Zolin <address@hidden>
> Acked-by: Roman Kagan <address@hidden>
> Signed-off-by: Denis V. Lunev <address@hidden>
> CC: Michael Roth <address@hidden>
> ---

> +++ b/qga/qapi-schema.json
> @@ -212,12 +212,33 @@
>    'returns': 'int' }
>  
>  ##
> +# @guest-pipe-open
> +#
> +# Open a pipe to in the guest to associated with a qga-spawned processes
> +# for communication.
> +#
> +# Returns: Guest file handle on success, as per guest-file-open. This
> +# handle is useable with the same interfaces as a handle returned by

s/useable/usable/

> +# guest-file-open.
> +#
> +# Since: 2.3
> +##
> +{ 'command': 'guest-pipe-open',
> +  'data':    { 'mode': 'str' },
> +  'returns': 'int' }

I'm not a fan of returning a bare 'int' - it is not extensible.  Better
is returning a dictionary, such as 'returns': { 'fd': 'int' }.  That
way, if we ever find a reason to return multiple pieces of information,
we just return a larger dictionary.

Yeah, I know guest-pipe-open breaks the rules here, and so consistency
may be an argument in favor of also breaking the rules.

I don't like 'mode' encoded as a raw string.  Make it an enum type (as
in { 'enum':'PipeMode', 'data':['read', 'write']} ... 'mode':'PipeMode')
or even a bool (as in 'read':'bool')

This only returns ONE end of a pipe (good for when the host is piping
data into the child, or when the child is piping data into the host).
But isn't your goal to also make it possible to string together multiple
child processes where the output of one is the input of the other (no
host involvement)?  How would you wire that up?

> +
> +##
>  # @guest-file-close:
>  #
>  # Close an open file in the guest
>  #
>  # @handle: filehandle returned by guest-file-open
>  #
> +# Please note that closing the write side of a pipe will block until the read
> +# side is closed.  If you passed the read-side of the pipe to a qga-spawned
> +# process, make sure the process has exited before attempting to close the
> +# write side.

How does one pass the read side of a pipe to a spawned child?  Can you
design the spawning API so that close cannot deadlock?

> +#
>  # Returns: Nothing on success.
>  #
>  # Since: 0.15.0
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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