[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 01/27] tools/libxl: Fix libxl__ev_child_inuse() check for not-yet-initialised children
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |