[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 05/10] xl_cmdimpl: improve return codes for memset commands



On Fri, 2016-04-08 at 10:26 +0200, Dario Faggioli wrote:
> On Wed, 2016-04-06 at 13:45 +0200, Paulina Szubarczyk wrote:
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3391,15 +3391,15 @@ static int set_memory_max(uint32_t domid,
> > const char *mem)
> >      memorykb = parse_mem_size_kb(mem);
> >      if (memorykb == -1) {
> >          fprintf(stderr, "invalid memory size: %s\n", mem);
> > -        exit(3);
> > +        return 1;
> >
> Mmmm.. I see no reason why this can't remain exit(). In fact, it should
> be turned int exit(EXIT_FAILURE), and there's Harmandeep's series --
> just resubmitted by me tonight-- outstanding that does that [1].

There was a discussion [2] that the exit() could be replaced by return 1
in the v1 of this patch, that is way I did here and in the following
commits. Should it be rather reverted? 

> 
> In any case, this patch is probably not necessary any longer, not
> because Harmandeep pending series, but because George take care of what
> I think you're trying to do in here in
> commit 0614c454209ac67016e2296577abfee9e9dcb012 already.

In that George's commit the set_memory_* functions return
EXIT_{FAILURE/SUCCESS}. Following the patches from Harmandeep's series I
was going to changed them to return 1/0 and return
EXIT_{FAILURE/SUCCESS} in main_* functions, after asking about that in
that thread [3], though, you said there are exceptions too that in [1].

> 
> Regards,
> Dario
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01099.html
[2]
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00384.html
[3]
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03422.html

Paulina



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.