On 12/31/2014 06:06 AM, Denis V. Lunev wrote: > From: Simon Zolin <szo...@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 <szo...@parallels.com> > Acked-by: Roman Kagan <rka...@parallels.com> > Signed-off-by: Denis V. Lunev <d...@openvz.org> > CC: Michael Roth <mdr...@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
signature.asc
Description: OpenPGP digital signature
