Re: [Xen-devel] [PATCH 04/26] xentoolcore, _restrict_all: Introduce new library and implementation

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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.Jackson@xxxxxxxxxxxxx>
> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel