All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Lasya Venneti <comethalley61@gmail.com>, Wei Liu <Wei.Liu2@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Lars Kurth <lars.kurth@citrix.com>
Subject: Re: [PATCH v3] dom variable error handled in Xenstore
Date: Thu, 29 Oct 2015 11:08:12 +0100	[thread overview]
Message-ID: <1446113292.28782.47.camel@citrix.com> (raw)
In-Reply-To: <CAAbK42_w=9UxpJcPTkRvT__dtOM9y+zd1_v7zdkdpm0KE6p3xQ@mail.gmail.com>


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

On Thu, 2015-10-29 at 00:42 +0530, Lasya Venneti wrote:
> 
> On 28 October 2015 at 06:30, Dario Faggioli <
> dario.faggioli@citrix.com> wrote:

> > > diff --git a/tools/xenstore/init-xenstore-domain.c
> > > @@ -42,6 +42,10 @@ static int build(xc_interface *xch, int argc,
> > > char** argv)
> > >       snprintf(cmdline, 512, "--event %d --internal-db", rv);
> > >
> > >       dom = xc_dom_allocate(xch, cmdline, NULL);
> > > +     if (dom == NULL) {
> > > +             rv = ENOMEM;
> > > +             goto err;
> > > +     }
> > >
> > On what basis did you decide that ENOMEM was a good return value?
> > 
> > I mean, have you checked what kind of value / error code is being
> > returned in the other cases (e.g., , xc_domain_setmaxmem(),
> > xc_domain_max_vcpus(), etc), if something goes wrong?
> > 

> Wei had advised me to raise ENOMEM (Out of memory). 
>
Ok, I missed / did not recall that. Wei is more knowledgeable and
authoritative than me in this area of the Xen architecture, so you're
doing the right thing listening to him.

Still, Wei, if you have five minute, I'd like your opinion on the below
reasoning on this subject.

> However,
> on your advice I checked the xc_domain_setmaxmem()  and 
> xc_domain_max_vcpus(). 

> On failure:
> ->xc_domain_setmaxmem returns a negative value. 
>
Exactly.

> function libxl__build_pre in xen/tools/libxl/libxl_dom.c returns 
> ERROR_FAIL when xc_domain_setmaxmem fails. 
> 
Err.. ok, but that is not that relevant here. That is libxl code, we
are somewhere else.

> ->xc_domain_max_vcpus returns a non zero value. 
>
Exactly again.

> It returns the same error value for libxl_build_pre function as
> above. 
> 
And irrelevant again.

> I must also add errno.h header to the file, I forgot to do that. I
> shall 
> do so in the next version.
> 
Mmm.. Why so?

> Request your comments, should I go with ENOMEM as we are finding
> (I think) 'amount' of dom memory allocation, and on failure it
> returns 
> NULL, or with the generic ERROR_FAIL. 
> 
I still fail to see how ERROR_FAIL from libxl may fit in here.

Anyway (and this is what I'd appreciate Wei's opinion on), it seems to
me that this fucntion is returning:
 - 0 on success;
 - -1 on early failure;
 - whatever the various xc_dom* functions return on later failure.

It is my recollection that libxc does (and when it does not, it's a bug
:-/), on error, return -1 and puts the specific error value in the
errno variable, rather than returning an error code directly.

Checking a bunch of the xc_dom* functions that are invoked from here
confirms that.

I think that this new return path being introduced in this patch should
be consistent with the described behavior.

Lasya, does this make things more clear? Wei, Thoughts?

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

      parent reply	other threads:[~2015-10-29 10:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28  0:12 [PATCH v3] dom variable error handled in Xenstore Lasya
2015-10-28  1:00 ` Dario Faggioli
2015-10-28 19:12   ` Lasya Venneti
2015-10-29 10:07     ` Wei Liu
2015-10-29 10:11       ` Dario Faggioli
2015-10-29 14:58         ` Lasya Venneti
2015-10-30 14:28           ` Dario Faggioli
2015-11-02 12:03             ` Ian Campbell
2015-10-29 10:08     ` Dario Faggioli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1446113292.28782.47.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=Wei.Liu2@citrix.com \
    --cc=comethalley61@gmail.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=lars.kurth@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.