xentoolcore, _restrict_all: Introduce new library and implementation
authorIan Jackson <ian.jackson@eu.citrix.com>
Thu, 14 Sep 2017 16:51:08 +0000 (17:51 +0100)
committerIan Jackson <Ian.Jackson@eu.citrix.com>
Wed, 11 Oct 2017 11:51:22 +0000 (12:51 +0100)
commitb08da5859b721122f16b98c8ceeeea496a0f3969
treed8a15bf9bad65c754839ea3ef51d52fd675e75c5
parent1462f9ea8f4219d520a530787b80c986e050aa98
xentoolcore, _restrict_all: Introduce new library and implementation

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@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
.gitignore
tools/Rules.mk
tools/libs/Makefile
tools/libs/toolcore/Makefile [new file with mode: 0644]
tools/libs/toolcore/handlereg.c [new file with mode: 0644]
tools/libs/toolcore/include/xentoolcore.h [new file with mode: 0644]
tools/libs/toolcore/include/xentoolcore_internal.h [new file with mode: 0644]
tools/libs/toolcore/libxentoolcore.map [new file with mode: 0644]
tools/libs/toolcore/xentoolcore.pc.in [new file with mode: 0644]