[ltt-dev] [RFC UST] ustctl return value

[Mathieu Desnoyers]

* David Goulet (david.goulet at polymtl.ca) wrote:
> ---
>  ustctl/ustctl.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/ustctl/ustctl.c b/ustctl/ustctl.c
> index d290975..152fc07 100644
> --- a/ustctl/ustctl.c
> +++ b/ustctl/ustctl.c
> @@ -170,6 +170,7 @@ int main(int argc, char *argv[])
>  {
>  	pid_t *pidit;
>  	int result;
> +	int retval = EXIT_SUCCESS;
>  	char *tmp;
>  	struct ust_opts opts;
>  
> @@ -256,6 +257,7 @@ int main(int argc, char *argv[])
>  					fprintf(stderr,
>  						"error while trying to list markers for"
>  						" PID %u\n", (unsigned int) *pidit);
> +					retval = EXIT_FAILURE;
> /* I'm just not sure about the right thing to do here. Let's use a simple
>  * test case. We use ustctl to list markers for a certain PID
>  * but this process died before we were able to list markers. Right now,
>  * ustctl is returning 0 even if the command fails. So, is it good to return
>  * an EXIT_FAILURE value here or not? It's not quite ustctl that failed... so...?
>  *
>  * I'm asking because, as now, there is NO way of knowing if the command
>  * pass to ustctl was successful without "analysing" the error message
>  * on stderr (string manip). For scripting, it's not good nor cool...
>  */

I think it is important to let ustctl continue if there is an error (so
a bogus parameter on command line with multiple options won't stop the
marshalling). What you propose here looks good: continue marshalling,
but raise an error returned when it exits.

We should probably audit the other commands in this switch, which seem
to simply ignore the return values of what they call.

Thanks,

Mathieu

>  					break;
>  				}
>  				unsigned int i = 0;
> @@ -356,6 +358,6 @@ int main(int argc, char *argv[])
>  		free(opts.regex);
>  	}
>  
> -	return 0;
> +	return retval;
>  }
>  
> -- 
> 1.7.2.2
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com