From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Egger <Christoph.Egger@amd.com>
Subject: Re: [PATCH v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
Date: Mon, 4 Jun 2012 15:11:23 +0200
Message-ID: <4FCCB3FB.5080504@amd.com>
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>
	<1337951405.26090.2.camel@Solace>
	<1337954436.22311.37.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1337954436.22311.37.camel@zakaz.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 Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Roger Pau Monne <roger.pau@citrix.com>, Dario Faggioli <raistlin@linux.it>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 05/25/12 16:00, Ian Campbell wrote:

> On Fri, 2012-05-25 at 14:10 +0100, Dario Faggioli wrote:
>> On Fri, 2012-05-25 at 12:03 +0100, Ian Jackson wrote:
>>> Ian Campbell writes ("Re: [PATCH v4] libxl: introduce LIBXL_DOMAIN_TYPE_INVALID"):
>>>> so having arranged to call that function at the right time we can assume
>>>> that type is a sensible value, and indeed setdefault makes this the
>>>> case.
>>>
>>> Right.
>>>
>> Ok.
>>
>>> The other situation where we can get _INVALID is if libxl__domain_type
>>> fails, which it can do.
>>>
>>> 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.
>>>
>>> If this is done, then general variables, parameters, etc. within libxl
>>> which are supposed to contain a libxl_domain_type will never contain
>>> _INVALID.
>>>
>> 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...
> 
> iff the compiler is smart enough to realise that in the type == INVALID
> case you have returned already before reaching the switch statement,
> otherwise you will need to have "case INVALID: abort()".


What is latest status of this patch? When will it go upstream?

> 
>>
>> Thanks and Regards,
>> Daio


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632