From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <raistlin@linux.it>
Subject: Re: [PATCH v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
Date: Fri, 25 May 2012 15:10:05 +0200
Message-ID: <1337951405.26090.2.camel@Solace>
References: <0a338fd74bab9eaeea74.1337873876@Solace>
	<1337939090.22311.22.camel@zakaz.uk.xensource.com>
	<1337941600.5761.19.camel@Solace>
	<1337942163.22311.27.camel@zakaz.uk.xensource.com>
	<20415.26393.141418.446541@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0515989756864972632=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20415.26393.141418.446541@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>, Roger Pau Monne <roger.pau@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org


--===============0515989756864972632==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-q5wGFuXA3xxro+ar1/oC"


--=-q5wGFuXA3xxro+ar1/oC
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-05-25 at 12:03 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH v4] libxl: introduce LIBXL_DOMAIN_TYPE_I=
NVALID"):
> > so having arranged to call that function at the right time we can assum=
e
> > that type is a sensible value, and indeed setdefault makes this the
> > case.
>=20
> Right.
>=20
Ok.

> The other situation where we can get _INVALID is if libxl__domain_type
> fails, which it can do.
>=20
> I think this should be handled by having places which call
> libxl__domain_type abandon operation and return an error if the
> libxl__domain_type fails.
>=20
> If this is done, then general variables, parameters, etc. within libxl
> which are supposed to contain a libxl_domain_type will never contain
> _INVALID.
>=20
I like this. I'll chase each call to that function and have the calle
failing if a DOMAIN_TYPE_INVALID is returned. Then, if I go this way,
can I also nuke both the 'case DOMAIN_TYPE_INVALID' _and_ the default
clauses from everywhere? I seem to think I could...

Thanks and Regards,
Daio

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


--=-q5wGFuXA3xxro+ar1/oC
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.4.12 (GNU/Linux)

iEYEABECAAYFAk+/hK0ACgkQk4XaBE3IOsTF2wCfWAK8IbTUPtV5gk0TKFNl3zjc
qUYAniBVpnbChHpB6SDEx8uSCrvzztSH
=wqrQ
-----END PGP SIGNATURE-----

--=-q5wGFuXA3xxro+ar1/oC--



--===============0515989756864972632==
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

--===============0515989756864972632==--