libxl callers should not be required to specify the backend if they
don't want to. So LIBXL_DISK_BACKEND_UNKNOWN should instruct libxl to
choose the backend for itself.
For now, we do this by simply treating it the same as BACKEND_TAP,
which itself falls back to other methods.
More thorough fixes for the disk handling will follow.
Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
---
tools/libxl/libxl.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c21cfe7..58df99c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -991,6 +991,21 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *dis
device.domid = domid;
device.kind = DEVICE_VBD;
+
+ /*
+ * Fixing the incoming backend type to try to decide on which
+ * backend to use. Unfortunately at the moment this code is
+ * utterly broken, but it more or less works.
+ */
+
+ /*
+ * Backend type UNKNOWN should mean "caller does not want to specify",
+ * not "break pointlessely". (Callers should not be required to
+ * specify the backend if they don't want to.)
+ */
+ if (disk->backend == LIBXL_DISK_BACKEND_UNKNOWN)
+ disk->backend = LIBXL_DISK_BACKEND_TAP;
+
/* If blktap is not available then fallback to qdisk */
if (disk->backend == LIBXL_DISK_BACKEND_TAP && !libxl__blktap_enabled(&gc))
disk->backend = LIBXL_DISK_BACKEND_QDISK;
@@ -1138,6 +1153,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx,
libxl_device_disk *disk)
dev = disk->pdev_path;
break;
case LIBXL_DISK_BACKEND_TAP:
+ case LIBXL_DISK_BACKEND_UNKNOWN:
if (disk->format == LIBXL_DISK_FORMAT_VHD ||
disk->format == LIBXL_DISK_FORMAT_RAW)
{
@@ -1175,7 +1191,6 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx,
libxl_device_disk *disk)
disk->pdev_path);
dev = disk->pdev_path;
break;
- case LIBXL_DISK_BACKEND_UNKNOWN:
default:
LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
"type: %d", disk->backend);
--
1.5.6.5
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|