Re: [Qemu-devel] [PATCH 5/8] guest agent: add guest-exec and guest-exec-status interfaces

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3393 bytes --]

On 12/31/2014 06:06 AM, Denis V. Lunev wrote:
> From: Simon Zolin <szolin@parallels.com>
> 
> Interfaces to execute/manage processes in the guest. Child process'
> stdin/stdout/stderr can be associated with handles for communication
> via read/write interfaces.
> 
> Signed-off-by: Simon Zolin <szolin@parallels.com>
> Acked-by: Roman Kagan <rkagan@parallels.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Michael Roth <mdroth@linux.vnet.ibm.com>
> ---

> +++ b/qga/qapi-schema.json
> @@ -759,3 +759,50 @@
>  ##
>  { 'command': 'guest-get-fsinfo',
>    'returns': ['GuestFilesystemInfo'] }
> +
> +##
> +# @guest-exec-status
> +#
> +# Check status of process associated with PID retrieved via guest-exec.
> +# Reap the process and associated metadata if it has exited.
> +#
> +# @pid: pid returned from guest-exec
> +#
> +# Returns: GuestExecStatus on success.  If a child process exited, "exit" is set
> +#          to the exit code.  If a child process was killed by a signal,
> +#          "signal" is set to the signal number.  If a child process is still
> +#          running, both "exit" and "signal" are set to -1.  On Windows,
> +#          "signal" is always set to -1.

That last sentence feels a bit too specific, and might even be wrong (it
IS possible to tell in Windows if something died due to Ctrl-C, which is
effectively SIGINT); so it might be better worded as 'If a guest cannot
reliably detect exit signals, "signal" will be -1'.

> +#
> +# Since: 2.3
> +##
> +{ 'type': 'GuestExecStatus',
> +  'data': { 'exit': 'int', 'signal': 'int',
> +            'handle_stdin': 'int', 'handle_stdout': 'int',
> +            'handle_stderr': 'int' } }

s/_/-/ throughout (that is, prefer dash, not underscore, for
handle-stdin and friends)

> +
> +{ 'command': 'guest-exec-status',
> +  'data':    { 'pid': 'int' },
> +  'returns': 'GuestExecStatus' }

Is there any way to query which pids are currently being tracked?
Suppose that the host's connection to qga is interrupted; on reconnect,
how can the host learn which pids are in use, to know how to grab status
of those pids?

> +
> +##
> +# @guest-exec:
> +#
> +# Execute a command in the guest
> +#
> +# @path: path or executable name to execute
> +# @params: #optional parameter list to pass to executable
> +# @env: #optional environment variables to pass to executable
> +# @handle_stdin: #optional handle to associate with process' stdin.
> +# @handle_stdout: #optional handle to associate with process' stdout
> +# @handle_stderr: #optional handle to associate with process' stderr

Inconsistent trailing '.'.  If any handle is omitted, what is used in
its place, effectively /dev/null?

> +#
> +# Returns: PID on success.
> +#
> +# Since: 2.3
> +##
> +{ 'command': 'guest-exec',
> +  'data':    { 'path': 'str', '*params': ['str'], '*env': ['str'],

I guess 'env' matches the usual exec*() interface, where the user is
responsible for passing 'name=value' pairs and behavior is not
necessarily defined if any of those strings aren't a name=value?

> +               '*handle_stdin': 'int', '*handle_stdout': 'int',
> +               '*handle_stderr': 'int' },

again, s/_/-/

> +  'returns': 'int' }
> 


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]