From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3] dom variable error handled in Xenstore Date: Thu, 29 Oct 2015 11:08:12 +0100 Message-ID: <1446113292.28782.47.camel@citrix.com> References: <1445991143-9165-1-git-send-email-comethalley61@gmail.com> <1445994047.2937.238.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6964783161961669541==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zrk83-0001Ft-JL for xen-devel@lists.xenproject.org; Thu, 29 Oct 2015 10:08:19 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lasya Venneti , Wei Liu Cc: xen-devel@lists.xenproject.org, Ian Campbell , George Dunlap , Lars Kurth List-Id: xen-devel@lists.xenproject.org --===============6964783161961669541== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nOlkJfNMIZUoQ1mxUDp0" --=-nOlkJfNMIZUoQ1mxUDp0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-10-29 at 00:42 +0530, Lasya Venneti wrote: >=20 > 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 =3D xc_dom_allocate(xch, cmdline, NULL); > > > + if (dom =3D=3D NULL) { > > > + rv =3D ENOMEM; > > > + goto err; > > > + } > > > > > On what basis did you decide that ENOMEM was a good return value? > >=20 > > 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? > >=20 > Wei had advised me to raise ENOMEM (Out of memory).=20 > 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=20 > xc_domain_max_vcpus().=20 > On failure: > ->xc_domain_setmaxmem returns a negative value.=20 > Exactly. > function libxl__build_pre in xen/tools/libxl/libxl_dom.c returns=20 > ERROR_FAIL when xc_domain_setmaxmem fails.=20 >=20 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.=20 > Exactly again. > It returns the same error value for libxl_build_pre function as > above.=20 >=20 And irrelevant again. > I must also add errno.h header to the file, I forgot to do that. I > shall=20 > do so in the next version. >=20 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=20 > NULL, or with the generic ERROR_FAIL.=20 >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-nOlkJfNMIZUoQ1mxUDp0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlYx8AwACgkQk4XaBE3IOsTZpgCgnW3bTxnkNFc51+NWEl9RryWn AIMAn0ArXG4iWvAxao1v4AY8AbyQyByJ =HDWU -----END PGP SIGNATURE----- --=-nOlkJfNMIZUoQ1mxUDp0-- --===============6964783161961669541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6964783161961669541==--