[libvirt] [PATCHv1 6/7] qemu_capabilities: qmperr pointer tracked in QMPCommand

[Jiri Denemark]

On Sat, May 05, 2018 at 12:48:48 -0500, Chris Venteicher wrote:
> Allow QEMU process to be started without requirement for caller to
> maintain handle to qmperr pointer.
> 
> The handle to qmperr pointer can be
> stored in QMPCommand structure (new way)
> stored in calling function's stack (original way).
> ---
>  src/qemu/qemu_capabilities.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index ac7569679c..431378cc02 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -4110,6 +4110,7 @@ struct _virQEMUCapsInitQMPCommand {
>      uid_t runUid;
>      gid_t runGid;
>      char **qmperr;
> +    char *qmperr_internal;
>      char *monarg;
>      char *monpath;
>      char *pidfile;
> @@ -4187,7 +4188,11 @@ virQEMUCapsInitQMPCommandNew(char *binary,
>  
>      cmd->runUid = runUid;
>      cmd->runGid = runGid;
> -    cmd->qmperr = qmperr;
> +
> +    if (qmperr)
> +        cmd->qmperr = qmperr; /* external storage */
> +    else
> +        cmd->qmperr = &cmd->qmperr_internal; /* cmd internal storage */
>  
>      /* the ".sock" sufix is important to avoid a possible clash with a qemu
>       * domain called "capabilities"

It's not really clear what you're trying to solve with this patch and
why it is needed.

Jirka