On Mon, Oct 09, 2017 at 04:57:06PM +0100, Ian Jackson wrote:
> In practice, qemu opens a great many fds. Tracking them all down and
> playing whack-a-mole is unattractive. It is also potentially fragile
> in that future changes might accidentally undo our efforts.
>
> Instead, we are going to teach all the Xen libraries how to register
> their fds so that they can be neutered with one qemu call.
>
> Right now, nothing will go wrong if some tries to link without
> -ltoolcore, but that will stop working as soon as the first other Xen
> library starts to register. So this patch will be followed by the
> stubdom build update, and should be followed by a
> MINIOS_UPSTREAM_REVISION updated.
>
> Sadly qemu upstream's configuration arrangements are too crude, being
> keyed solely off the Xen version number. So they cannot provide
> forward/backward build compatibility across changes in xen-unstable,
> like this one. qemu patches to link against xentoolcore should be
> applied in qemu upstream so avoid the qemu build breaking against the
> released version of Xen 4.10.
>
> Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com>
> Acked-by: Wei Liu <wei.l...@citrix.com>
> ---
> diff --git a/tools/libs/toolcore/handlereg.c b/tools/libs/toolcore/handlereg.c
> new file mode 100644
> index 0000000..efeffb1
> --- /dev/null
> +++ b/tools/libs/toolcore/handlereg.c
> +static pthread_mutex_t handles_lock = PTHREAD_MUTEX_INITIALIZER;
> +static XENTOOLCORE_LIST_HEAD(, Xentoolcore__Active_Handle) handles;
> +
> +static void lock(void) {
> + int e = pthread_mutex_unlock(&handles_lock);
Shouldn't this call pthread_mutex_lock? Right now lock and unlock do
the same thing.
> + assert(!e);
> +}
> +
> +static void unlock(void) {
> + int e = pthread_mutex_unlock(&handles_lock);
> + assert(!e);
> +}
> +
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
