Re: [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2354 bytes --]

On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:

> Looking at those links, I'm not sure that either you or myself was
> thinking
> of using EXIT_* as function return values, just that the eventual
> process
> exit would become one of those values instead of some negative
> number.
>
Exactly.

> Although the thread doesn't look like it is too clear if it is
> talking
> about return values from functions vs. process exit codes.
> 
Well, independently from the thread, I certainly meant that I think
EXIT_* should be used as process exit status, not as internal
functions' return value.

> I think what I would have been expecting is for the xl internal error
> code
> would become EXIT_* either in the call to exit() or the return from
> main
> instead of being the process exit code directly.
> 
But, in this specific case, and in cases of main_foo() functions in
xl_cmdimpl.c, it's exactly like that, isn't it?

    ...
    if (cspec) {
        if (dryrun_only && !cspec->can_dryrun) {
            fprintf(stderr, "command does not implement -N (dryrun) option\n");
            ret = 1;
            goto xit;
        }
        ret = cspec->cmd_impl(argc, argv);
    } else if (!strcmp(cmd, "help")) {
        help(argv[1]);
        ret = 0;
    } else {
        fprintf(stderr, "command not implemented\n");
        ret = 1;
    }

 xit:
    return ret;
}

(from main() in xl.c)

> Seeing "return EXIT_FOO" outside of a main function seems rather
> strange to
> me.
> 
Well, same here. Except, given xl architecture, I was considering
main_foo() functions in xl_cmdimpl.c as some king of extensions of the
actual main function.

The alternative would be to always use, say, 0 and 1 in xl_cmdimpl.c,
and then convert them to EXIT_SUCCESS or EXIT_FAILURE in xl.c (for
return-s, of course, exit()-s need to use them no matter where they
are).

I'm fine with either, so, if you prefer the latter, I certainly can
arrange for doing things that way.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel