From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 01/27] tools/libxl: Fix
 libxl__ev_child_inuse() check for not-yet-initialised children
Date: Tue, 16 Jun 2015 16:26:10 +0100
Message-ID: <1434468370.13744.226.camel@citrix.com>
References: <1434375880-30914-1-git-send-email-andrew.cooper3@citrix.com>
	<1434375880-30914-2-git-send-email-andrew.cooper3@citrix.com>
	<1434460912.13744.147.camel@citrix.com>	<55802669.6070209@citrix.com>
	<21888.10454.890849.389495@mariner.uk.xensource.com>
	<55802D3B.5050805@citrix.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: <55802D3B.5050805@citrix.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: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Yang Hongyang <yanghy@cn.fujitsu.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 2015-06-16 at 15:05 +0100, Andrew Cooper wrote:
> On 16/06/15 14:47, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH 01/27] tools/libxl: Fix libxl__ev_child_inuse() check for not-yet-initialised children"):
> >> It is possible that one bit fails before it can be calculated whether
> >> the second bit needs to start or not.
> >>
> >> At the moment, all bits in libxl in this area do initialisation
> >> immediately before use; most bits are even initialised in the function
> >> which starts their actions.  Some bits are initialised differently
> >> depending on the path taken to get to the initialisation site. 
> > As a rule of thumb a function libxl__initiate_foo_ which takes a
> > libxl__foo_state* should do this initialisation for the whole
> > libxl__foo_state.
> >
> > I don't see why you can't do that.
> 
> The only example of libxl__initiate_foo_ is
> libxl__initiate_device_remove() which starts the first action involved
> with removing a device.
> 
> I will see what I can do, but there are areas of this code which can't
> have their initialisation brought any further forward.

I think you need to consider "make the struct into some known good
initial/default state" as something separate from "turn the struct into
a useful thing to achieve its goal". Only the first bit needs to move
IMHO (although if they both can that is nice too)

Ian.