Re: [PATCH 01/27] tools/libxl: Fix libxl__ev_child_inuse() check for not-yet-initialised children

[Ian Campbell <ian.campbell@citrix.com>]

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.