Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned 
middle children"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Also, remove erroneous comment suggesting that `death' callback
> > parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> > are no callers which pass NULL.

> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

Thanks.

> > -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> > +/* Precondition: Attached or Detaching; caller has logged failure reason.
> > + * Results: Detaching, or Attached Failing */
> 
> Is it Failing or Failed? You use Failed elsewhere.

`Failed' will do.  Fixed.

> [...]
> > @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc 
> > *gc, uint32_t domid);
> >   *
> >   * Higher-level double-fork and separate detach eg as for device models
> >   *
> > - * Each libxl__spawn_state is in one of the conventional states
> > - *    Undefined, Idle, Active
> > + * Each libxl__spawn_state is in one of these states
> > + *    Undefined, Idle, Attached, Detaching
> 
> "Attached OK" and "Attached Failed" as described above aren't really
> full states, just sub-states?

Yes.  I have clarified this:

 * The difference between Attached OK and Attached Failed is not
 * directly visible to callers - callers see these two the same,
 * although of course Attached OK will hopefully eventually result in
 * a call to detached_cb, whereas Attached Failed will end up
 * in a call to failure_cb.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel