Re: [Xen-devel] [PATCH v6 00/10] libxl: event API

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-01-06 at 20:34 +0000, Ian Jackson wrote:
> This series is the latest revision of my event handling API.  It
> includes changes in response to a number of comments made.  It also
> includes a few new consequential patches and unrelated
> fixes/improvements, as usual.
> 
> The most significant difference is the new "libxl__egc" type which is
> used instead of libxl__gc by event-generating functions.  This
> prevents accidental violation of the callback reentrancy rules.
> 
> I'm still working on this series.  At the moment I'm working on
> providing asynchronous calls for long-running operations; this
> requires more support machinery which is still not finalised.

Do we require that the async stuff is complete before we can commit the
event stuff? Obviously the former makes heavy use of the later so I
guess there will be "knock-back" effects as you implement it but the
series is becoming quite unwieldy (and long lived) so maybe it'd be
better to push part 1 and fix it up as necessary when you do the async
stuff?

> 
> Of the resulting patches in this series,
> 
> These should perhaps go in soon:
>  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
>  03/10 libxl: move a lot more includes into libxl_internal.h
>  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
>  05/10 libxl: Fix leaks on context init failure
>  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> 
> This one has now been tested and can go in IMO:
>  02/10 xenstore: New function xs_path_is_subpath

I agree that all the above can go in. I think I've acked them all.

> These are the meat:
>  07/10 libxl: New API for providing OS events to libxl
>  08/10 libxl: New event generation API
>  10/10 libxl: Permit multithreaded event waiting
> 
> And this one has become rendered obsolete.  If we are to retain the
> new libxl__egc structure, I will drop it.  Otherwise it may still be
> needed, and it's disruptive, which is why I haven't dropped it from my
> series yet:
>  06/10 DROP: libxl: rename libxl__free_all
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel