To replace yajl.
Introduce XEN_JSON_LIBS variable, to be able to remove "-lyajl" later.
As a first step, the variable will have both or only -lyajl. Then
commit "configure: Use json-c by default, fallback to yajl" will make
a change to only have one or the other once the code is ready to build
with only json-c.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
This patch adds a systemd sleep hook script to stop the xen-watchdog
service before system suspend and start it again after resume.
Stopping the watchdog before a system suspend operation may look unsafe.
Let's imagine the following situation: 'systemctl suspend' does not
interact with the running service at all. In such a case, the Xen
watchdog daemon freezes just before suspend. If this happens, for
example, right before sending a ping, and Xen has not yet marked the
domain as suspended (is_shutting_down), the Xen watchdog timer may
trigger a false alert.
This is an almost impossible situation, because typically:
ping time = watchdog timeout / 2
and the watchdog timeout is usually set to a relatively large value
(dozens of seconds).
Still, this is more likely with very short watchdog timeouts. It may
happen in the following scenarios:
* Significant delays occur between freezing Linux tasks and
triggering the ACPI or PSCI sleep request or handler.
* Long delays happen inside Xen between the entrance to the sleep
trigger and the actual forwarding of the sleep request further.
A similar situation may occur on resume with short timeouts. During the
resume operation, Xen restores timers and the domain context. The Xen
watchdog timer also resumes. If it schedules the domain right before the
watchdog timeout expires, and the daemon responsible for pinging is not
yet running, a timeout might occur.
Both scenarios are rare and typically require very small watchdog
timeouts combined with significant delays in Xen or the Linux kernel
during suspend/resume flows.
Conceptually, however, if activating and pinging the Xen watchdog is the
responsibility of the domain and its services, then the domain should
also manage the watchdog service/daemon lifecycle. This is similar to
what is already done by the Xen watchdog driver inside the Linux kernel.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The final user was blktap2, removed in Xen 4.13.
Strip out the ./configure check for it, and stop explicitly installing it in
the FreeBSD testing.
Fixes: 2a556b63a2 ("Drop blktap2")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
There are no more users, and we want to disuade people from introducing new
users just for sd_notify() and friends. Drop the dependency.
We still want the overall --with{,out}-systemd to gate the generation of the
service/unit/mount/etc files.
Rerun autogen.sh, and mark the dependency as removed in the build containers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
The only in-tree user of libfsimage is pygrub. Now that it is possible
to disable the build of pygrub, the same should be possible for
libfsimage.
Add an option for controlling the build of libfsimage. The default is
on if pygrub is being built, and off if it isn't. Without pygrub the
build of libfsimage can be enabled via --enable-libfsimage.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Add a "--disable-pygrub" option for being able to disable the build
and installation of pygrub.
There are two main reasons to do so:
- A main reason to use pygrub is to allow a PV guest to choose its
bitness (32- or 64-bit). Pygrub allows that by looking into the boot
image and to start the guest in the correct mode depending on the
kernel selected. With 32-bit PV guests being deprecated and the
possibility to even build a hypervisor without 32-bit PV support,
this use case is gone for at least some configurations.
- Pygrub is running in dom0 with root privileges. As it is operating
on guest controlled data (the boot image) and taking decisions based
on this data, there is a higher security risk. Not being possible
to use pygrub is thus a step towards a reduction of attack surface.
Default is still to build and install pygrub.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
According to openpty(3) it is required to include <pty.h> to get the
prototypes for openpty() and login_tty(). But this is not what the
function AX_CHECK_PTYFUNCS actually does. It makes no attempt to include
the required header.
The two source files which call openpty() and login_tty() already contain
the conditionals to include the required header.
Remove the bogus m4 file to fix build with clang, which complains about
calls to undeclared functions.
Remove usage of INCLUDE_LIBUTIL_H in libxl_bootloader.c, it is already
covered by inclusion of libxl_osdep.h.
Remove usage of PTYFUNCS_LIBS in libxl/Makefile, it is already covered
by UTIL_LIBS from config/StdGNU.mk.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Use both ZLIB_CFLAGS and ZLIB_LIBS instead of cherry-picking flags
from a single "ZLIB" variable.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
This hunk was missing from the work to drop gettext as a build dependency.
Fixes: e21a6a4f96 ("tools: Drop gettext as a build dependency")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
This is a weird variable to have in the first place. The only user of it is
XSM's CONFIG_SHELL, which opencodes a fallback to sh. The scripts are shebang
sh, which is already necessary to support non-Linux build environments.
Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop the
CONFIG_SHELL, and drop the $BASH variable to prevent further use.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
By default, if the go compiler is found by the configure script, build
the golang tools. If the compiler is not found, and --enable-golang was
not explicitly set, do not build to the golang tools.
The corresponding make variable is CONFIG_GOLANG. Remove CONFIG_GOLANG
from tools/Rules.mk since the variable is now set by configure in
config/Tools.mk.
Signed-off-by: Nick Rosbrook <rosbrookn@ainfosec.com>
Acked-by: Wei Liu <wl@xen.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Blktap2 is effectively dead for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. libxl no longer supports TAP disk backend, with appropriate assertions
added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend
3. Remove blktap2 entry from MAINTAINERS
A patch to remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
So a user can decide whether to compile a PV shim as part of the tools
build. Note that the default behavior is preserved, which is to build
a PV shim when the target or host (if target is unset) architecture is
64bit x86.
Requested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.s ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
In "build: add autoconf to replace custom checks in tools/check"
--enable-githttp was introduced. But we missed this comment where it
was advertised.
Also, that commit had the effect of uncondtionally setting GIT_HTTP
from the configure variable. But the env var has been advertised in
some places as the way to specify this behaviour, and overriding it is
just unfriendly.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs' option to configure which, if specified,
will cause '--enable-virtfs' to be passed to QEMU's configure. This will
cause the dependency on libcap and libattr to be called out if the packages
are not in installed.
For completeness, specifying 'disable-9pfs' will cause '--disable-virtfs' to
be passed to QEMU's confgure and not specifying an option will keep the
previous behaviour of predicating VirtFS on whether the libcap and libattr
packages are installed.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This option lets user specify which binary is to be used as ipxe. If
it is specified, the in-tree ipxe will not be built. This option is in
line with other --with-system-* options we provide.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Curl and xml2 are not required anymore since 185bb58be3 ("tools: drop
libxen") removed their only user.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh ]
Blktap2 is effectively dead code for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. Now libxl no longer supports TAP disk backend, appropriate assertions
are added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend in doc
3. Remove relevant entries in MAINTAINERS
A patch to actually remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: George Dunlap <George.Dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
COLO and Remus net buffer support both depend on the availability of
libnl. Use a generic name.
No functional changes.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
In 16181cbb (tools: Honor Config.mk debug value, rather than setting our
own), configure doesn't set debug variable anymore. There is, however,
one place that was missed. The file config/Tools.mk.in was still
expecting a @debug@ value from configure. After 16181cbb that value
remained "debug := @debug@" all the time because configure didn't
substitute it.
The consequence was that we couldn't get a debug build even if debug was
set to "y" in Config.mk.
Fix this by removing the stray line "debug := @debug@" in Tools.mk.in.
Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: George Dunlap <george.dunlap@citrix.com>
binutils 2.22 changed ld default from --copy-dt-needed-entries
to -no-copy-dt-needed-entries. This revealed that some objects
are linked implicitly with libtinfo and newer ld fails to build
relevant executables.
Below is short explanation why we should not do that...
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange says:
The default behaviour for ld (my note: before version 2.22) allows
users to 'indirectly' link to required objects/libraries through
intermediate objects/libraries. While this is convenient, it can
also be dangerous because it makes your program's dependencies tied
to the dependencies of other objects. If those objects ever change
their linkages, they can break your program without any changes
to your own code!
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We are going to need this to generate the userspace flask.h header.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh ]
Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781). As a result, on
those systems, debug builds fail.
Work around this problem as follows:
* In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
* If detected, set the new autoconf substitution and make variable
PY_NOOPT_CFLAGS to -O1.
* In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
(which will override the -O0 with -O1 if required).
Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact. A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Euan Harris <euan.harris@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Don Slutz <dslutz@verizon.com>
This was disabled by default in Xen 4.4. Since xend has now been
removed from the tree I don't believe anything is using it.
We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional
otherwise it defaults to y and doesn't build.
This patch does all the ground work, the tools/blktap directory will
be removed in the next (*huge*) patch.
Note that this has no impact on blktap2, which is what libxl supports.
blktap1 was only usable via xend which has already been removed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This replaces config/Linux.modules with a configure option. As a result
of this change only a single xencomons.in is required, instead of a
xencomons.in.in and sed hackery.
After this change blktap2 and blktap will be loaded at the same time.
This is already done in out-of-tree xencommons scripts, and systemd will
load both modules as well. No harm is expected by loading both modules.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
Libnl3 is required for controlling Remus network buffering.
This patch adds dependency on libnl3 (>= 3.2.8) to autoconf scripts.
It also provides the ability to configure tools without libnl3 support
i.e., without network buffering support.
When there is no network buffering support, libxl__netbuffer_enabled()
returns 0, otherwise returns 1. The callers of this api will be
introduced in the rest of the series.
NOTE: This patch changes tools/configure.ac, please rerun
autogen.sh while applying the patch.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Reviewed-by: Wen Congyang <wency@cn.fujitsu.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This adds the systemd xen service / module files and integrates
support into the build system.
This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.
When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.
These are originally based on the Fedora systemd files.
Changes made from Fedora's systemd files:
* split sockets into two files to claim different permissions
* Use /bin/sh -c exec to for a simple launcher implementation
* enables systemd socket activation for C xenstored and Ocaml
oxenstored
* use sd_notify(), so change the service to Type=notify, because of
this we remove the PIDFile specification as we don't care for it, and let
systemd do its magic for us, this also means we don't have to fork
so we use --no-fork with systemd
* defines a modules-load.d, its original source file will be shared
between systemd and old init systems
* simplify service files with ConditionVirtualization=xen which uses
the built in systemd virtualization backend detection, these
service files will not be available to start on systems that do not
boot with xen as a hypervisor
* use autoconf to replace @variable@ paths for us which piggy
backs on top of the latest autoconf changes to xen
* removes oxenstored service file in favor of a system variable which
controls which which xentored to use at run time, we avoid multiple
service files this way.
* simplifies startup to not require polling on the sockets
as initial socket management is handled by systemd, we just
take on the socket later once anything pokes at it, a simple nc -U
(as root) on any of the sockets files can activate the service for example.
Anything queued up will be sent to us once we start. Socket activation
should in theory also let us dynamically switch between xenstores but more
importantly we could upgrade xenstored while keeping all active
socket communication queued up, but in order to take advantage of
this we eventually would need to remove the requirement of not being
able to bring down the xenstored. Even though active sockets are
supported since most libxl communication doesn't triggger a check
on the unix socket first administrators are encouraged to enable
the xenstored.service to triggger an initialization of the xenstored
upon bring up. Some systems also never use unix sockets for
communication with the xenstored and as such active sockets will
not be used there.
* allow for xenstored configuration through *either* of these
configuration files:
- /etc/sysconfig/xenstored
- /etc/default/xenstored
The /etc/default/xenstored will let debian based systems do
the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
with sysconfig. We leave these files all commented out by default
though given that for systemd we want to encourage not using them.
* ensures we create the run directory as most systems will likely
be using a tmpfs for run dirs for the pid files
* Some systems define the selinux context in the systemd Option for the
/var/lib/xenstored tmpfs:
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
For the upstream version we remove that and let systems specify the
context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
$XENSTORED_MOUNT_CTX variable, with a default to none.
* takes advantage of the shared xendomains helper for the xendomains
service
* Add the new dom0 that gets kicked off for disk backend access into
its own systemd service associated to xen
We end up with these systemd files:
General requirements:
* proc-xen.mount
* var-lib-xenstored.mount
xenstored:
* xenstored.service
* xenstored.socket
* xenstored_ro.socket
* xenconsoled.service
* xen-qemu-dom0-disk-backend.service.in
Optional:
* xendomains.service
* xen-watchdog.service
As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.
The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.
If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).
Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
Support
./configure --host=x86_64-rumpxen-netbsd
./configure --host=i386-rumpxen-netbsd
Setting --host tells configure we are cross compiling and therefore
has various automatic effects.
But in this patch we make some deliberate changes as well:
* We disable a large number of configure tests for libraries
etc. which don't exist.
* We set CONFIG_RUMP in Tools.mk.
* Hence, we automatically set XEN_OS.
(I have only tested the 32-bit build but I think the 64-bit build
should work just as well.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
v3: Add comment to `fi'
v2: Mention x86_64.
Drop an erroneous whitespace change.
blktap2 will be enabled by default on Linux systems only, also give
the oportunity to disable it from configure.
Remove the gate in the Makefile that only allows enabling blktap{1,2}
on Linux, since this is now done in a more flexible way on configure.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
The manage-vtpmmgr.pl script is an example client for interacting with
the TPM Manager; it is intended to run in a management domain with a
vTPM (which may be dom0). It is used to create and manage vTPMs and
vTPM groups.
The calc.pl script is an example manager of a vTPM group. It signs
the configuration lists used by the TPM Manager with a locally held
private key.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This was a C interface to a very early version of the XenAPI, it has not kept
up with developments to the API e.g. in xapi.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
I've retained xen.lowlevel.{xc,xs} since they seem more widely useful. I also
kept xen.lowlevel.xl even though it is disabled by default and IMHO useless in
its current form.
I've tried to clean up the various associated bits like example configs, init
scripts, udev rules etc but no doubt I have missed something, those can easily
be cleaned up later.
I've also removed xm-test since although it could in theory be reworked to
test xl it hasn't been touched for years. If someone wants to resurrect it
then they could do so via the git history.
This has been built but not runtime tested.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Clean out some .*ignore cruft
Remove some xm/xend docs.
Debian Jessie at least contains an ovmf package that includes
/usr/share/ovmf/OVMF.fd. It's also possible that user may want to supply
his/her own ovmf binary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
If this option is given don't bother building seabios ourselves.
Likely to be handy for distros who have an existing seabios
package which they want to reuse.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
If this option is given don't bother building qemu-xen ourselves. Likely to be
handy for distros who have an existing qemu package which they want to reuse.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Now that we have upstream qemu people may want to avoid building this extra
code.
There is a little bit of trickery in stubdom/configure.ac to ensure that the
ioemu stubdom is only built if qemu-traditional is enabled.
libxl will return an error if a caller tries to build a domain using
qemu-xen-traditional when this support was disabled at build time. Since
qemu-xen-traditional has been historically tightly bound to the Xen releases I
don't see any value in supporting "3rd party" provision of
qemu-xen-traditional.
We also do not want/need this on ARM therefore default is on for x86 and off
otherwise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- trivial conflicts in Tools.mk.in and tools/configure.ac.
Reran autogen.sh ]
I don't think there are any dom0's around whose kernels support only blktap1
and not something newer like blktap2 or qdisk. Certainly not that you would
want to run Xen 4.4 on.
libxl will never use blktap1.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Anthony PERARD