add libxl support for blktap3 and introduce the blktap3 build system

tools/libxl/libxl_types_internal.idl +0 -0

     ])
 
 libxl__console_backend = Enumeration("console_backend", [

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:17
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3 device type

Quoted 1 line · Thanos Makatos

This device is used when tap is specifed as the disk backend, instead

of vbd.

Quoted 1 line

tools/libxl/libxl.c int libxl__device_from_disk(libxl__gc *g · line 1745

Quoted 9 lines

diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c

tools/libxl/libxl.c +1 -1

@@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
             device->backend_kind = LIBXL__DEVICE_KIND_VBD;
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;

Presumably as well as this change a bunch of related infrastructure changes are needed? I'd suggest putting all those first and making this switch at the end, so that xl remains functional at each point in the series.

Quoted 6 lines

tools/libxl/libxl.c +0 -0

             break;
         case LIBXL_DISK_BACKEND_QDISK:
             device->backend_kind = LIBXL__DEVICE_KIND_QDISK; diff -r

3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl Wed Oct 24 17:22:39

2012 +0100

Quoted 1 line

+++ b/tools/libxl/libxl_types_internal.idl Wed Oct 24 17:24:01

2012 +0100

tools/libxl/libxl.c libxl__device_kind = Enumeration("device · line 22

Quoted 5 lines

tools/libxl/libxl.c +1 -0

@@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "XENIO"),

I know this is what it is called internally but for libxl purposes can we use BLKTAP or something descriptive like that?

Quoted 9 lines

tools/libxl/libxl.c +0 -0

     ])
 
 libxl__console_backend = Enumeration("console_backend", [

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:19
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3 in libxl Makefile

Quoted 5 lines

diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile

tools/libxl/Makefile +0 -0

@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
 

tools/libxl/Makefile LIBUUID_LIBS += -luuid endif · line 25

Quoted 6 lines

tools/libxl/Makefile +2 -1

 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
 $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS)
 $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
+$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)

What happened to LDLIBS_libblktapctl here?

Quoted 5 lines

tools/libxl/Makefile +0 -0

 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -77,7 +77,8 @@ LIBXL_OBJS =

flexarray.o libxl.o libxl_c
libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-

y) LIBXL_OBJS

Quoted 5 lines

+= _libxl_types.o libxl_flask.o _libxl_types_internal.o

-$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include

$(XEN_ROOT)/tools/config.h \

tools/libxl/Makefile LIBXL_OBJS = flexarray.o libxl.o libxl_c · line 81

Quoted 1 line

tools/libxl/Makefile +1 -0

+	$(CFLAGS_libblktapctl)

This Makefile already contains
CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
so I think this change is redundant (or else incomplete).

Ian.

Make libxl__blktap_devpath return an error code instead of the device,
since there is no device in dom0 any more.

Amend the libxl code that uses this functions accordingly.

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c

tools/libxl/libxl.c +12 -6

@@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
                 break;
 
             case LIBXL_DISK_BACKEND_TAP:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-                if (!dev) {
-                    LOG(ERROR, "failed to get blktap devpath for %p\n",
-                        disk->pdev_path);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (rc) {
+                    LOG(ERROR, "failed to get blktap devpath for %s: %s\n",
+                        disk->pdev_path, strerror(rc));
                     rc = ERROR_FAIL;
                     goto out;
                 }
+                dev = NULL;
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                     libxl__device_disk_string_of_format(disk->format),

@@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (!rc) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "error getting tapdisk: %s", strerror(rc));
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +2 -2

@@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
     return 1;
 }
 
-char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
-    return NULL;
+    return -ENOSYS;
 }
 
 int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h

tools/libxl/libxl_internal.h +2 -3

@@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
 /* libxl__blktap_devpath:
  *    Argument: path and disk image as specified in config file.
  *      The type specifies whether this is aio, qcow, qcow2, etc.
- *    returns device path xenstore wants to have. returns NULL
- *      if no device corresponds to the disk.
+ *    returns 0 on success, an error code otherwise 
  */
-_hidden char *libxl__blktap_devpath(libxl__gc *gc,
+_hidden int libxl__blktap_devpath(libxl__gc *gc,
                                     const char *disk,
                                     libxl_disk_format format);
 

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:22
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change libxl__blktap_devpath prototype to return an error code

Quoted 1 line · Thanos Makatos

Make libxl__blktap_devpath return an error code instead of the

device,

Quoted 1 line

since there is no device in dom0 any more.

Does this function eventually go away then? Or will it eventually return some sort of metadata which can be used to connect to the created tap device?

tools/libxl/libxl.c static void device_disk_add(libxl__egc * · line 1847

Quoted 11 lines

Amend the libxl code that uses this functions accordingly.

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c

tools/libxl/libxl.c +0 -1

@@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
                 break;
 
             case LIBXL_DISK_BACKEND_TAP:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,

disk->format);

tools/libxl/libxl.c static void device_disk_add(libxl__egc * · line 1849

Quoted 2 lines

tools/libxl/libxl.c +0 -2

-                if (!dev) {
-                    LOG(ERROR, "failed to get blktap devpath for

%p\n",

tools/libxl/libxl.c static void device_disk_add(libxl__egc * · line 1847

Quoted 2 lines

tools/libxl/libxl.c +1 -1

-                        disk->pdev_path);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path,

disk->format);

tools/libxl/libxl.c static void device_disk_add(libxl__egc * · line 1849

Quoted 2 lines

tools/libxl/libxl.c +2 -0

+                if (rc) {
+                    LOG(ERROR, "failed to get blktap devpath for %s:

%s\n",

Quoted 10 lines

tools/libxl/libxl.c +2 -0

+                        disk->pdev_path, strerror(rc));
                     rc = ERROR_FAIL;
                     goto out;
                 }
+                dev = NULL;
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
 

libxl__device_disk_string_of_format(disk->format),

tools/libxl/libxl.c void libxl__device_disk_local_initiate_a · line 2281

Quoted 6 lines

tools/libxl/libxl.c +1 -2

@@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path,

disk->format);

tools/libxl/libxl.c void libxl__device_disk_local_initiate_a

Quoted 3 lines

tools/libxl/libxl.c +3 -0

+                if (!rc) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "error getting tapdisk: %s",

strerror(rc));

Quoted 11 lines

tools/libxl/libxl.c +3 -0

+                    rc = ERROR_FAIL;
+                    goto out;
+                }
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +0 -0

@@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
     return 1;

tools/libxl/libxl_blktap3.c int libxl__blktap_enabled(libxl__gc *gc) · line 13

Quoted 10 lines

tools/libxl/libxl_blktap3.c +2 -2

 }
 
-char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
-    return NULL;
+    return -ENOSYS;
 }
 
 int libxl__device_destroy_tapdisk(libxl__gc *gc, const char

*be_path)

Quoted 2 lines

{ diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h Wed Oct 24 17:24:53 2012

+0100

Quoted 1 line

+++ b/tools/libxl/libxl_internal.h Wed Oct 24 17:25:02 2012

+0100

Quoted 18 lines

tools/libxl/libxl_blktap3.c +2 -3

@@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
 /* libxl__blktap_devpath:
  *    Argument: path and disk image as specified in config file.
  *      The type specifies whether this is aio, qcow, qcow2, etc.
- *    returns device path xenstore wants to have. returns NULL
- *      if no device corresponds to the disk.
+ *    returns 0 on success, an error code otherwise
  */
-_hidden char *libxl__blktap_devpath(libxl__gc *gc,
+_hidden int libxl__blktap_devpath(libxl__gc *gc,
                                     const char *disk,
                                     libxl_disk_format format);
 

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 13 lines

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:22
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change libxl__blktap_devpath prototype to return an error code

Quoted 1 line · Thanos Makatos

Make libxl__blktap_devpath return an error code instead of the

device,

Quoted 1 line

since there is no device in dom0 any more.

Quoted 3 lines

Does this function eventually go away then? Or will it eventually return some sort of metadata which can be used to connect to the created tap device?

As in blktap2, it creates the tapdisk process, but doesn't return any metadata, so it's still required. I guess changing the name of the function would clarify it.

Don't check if blktap is enabled since it will always be enabled (no blktap/blkback requirement anymore).

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +0 -4

@@ -1,10 +1,6 @@
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
-int libxl__blktap_enabled(libxl__gc *gc) {
-    return 1;
-}
-
 int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
     return -ENOSYS;

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c

tools/libxl/libxl_device.c +0 -7

@@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
 
     case LIBXL_DISK_BACKEND_TAP:
         if (a->disk->script) goto bad_script;
-
-        if (!libxl__blktap_enabled(a->gc)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
-                       " unsuitable because blktap not available",
-                       a->disk->vdev);
-            return 0;
-        }
         if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
               a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
             goto bad_format;

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:24
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap is available

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:

Quoted 2 lines

Don't check if blktap is enabled since it will always be enabled (no blktap/blkback requirement anymore).

I think this needs to stay until the *BSD dom0's implement the necessary kernel drivers (gnttab/gntalloc etc) such that blktap3 can run on them.
Currently we use libxl_noblktap2.c on those platforms and I think until then we need to retain a libxl_noblktap3.c for use there.

Perhaps even on Linux we would want a sanity check that the drivers are present and loaded etc?

Quoted 20 lines

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +0 -4

@@ -1,10 +1,6 @@
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
-int libxl__blktap_enabled(libxl__gc *gc) {
-    return 1;
-}
-
 int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
     return -ENOSYS;

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c

tools/libxl/libxl_device.c static int disk_try_backend(disk_try_bac · line 182

Quoted 6 lines

tools/libxl/libxl_device.c +0 -3

@@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
 
     case LIBXL_DISK_BACKEND_TAP:
         if (a->disk->script) goto bad_script;
-
-        if (!libxl__blktap_enabled(a->gc)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend

tap"

Quoted 12 lines

tools/libxl/libxl_device.c +0 -4

-                       " unsuitable because blktap not available",
-                       a->disk->vdev);
-            return 0;
-        }
         if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
               a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
             goto bad_format;

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 3 lines

Perhaps even on Linux we would want a sanity check that the drivers are present and loaded etc?

We could ensure that the tapdisk binaries are present, apart from that I don't see anything else we could check.

Quoted 6 lines

Quoted 3 lines

Perhaps even on Linux we would want a sanity check that the drivers are present and loaded etc?

We could ensure that the tapdisk binaries are present, apart from that I don't see anything else we could check.

Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it needs?

-----Original Message-----
From: Ian Campbell
Sent: 30 October 2012 07:42
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap is available

Quoted 4 lines

Quoted 3 lines

Perhaps even on Linux we would want a sanity check that the drivers are present and loaded etc?

Quoted 1 line

We could ensure that the tapdisk binaries are present, apart from

that

Quoted 1 line

I don't see anything else we could check.

Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it needs?

Ian.

tools/blktap3/Makefile new file +6 -0

+
+clean: ;
+
+install: ;
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 1 line

+build: ;

What does the ";" in this syntax do?

Hello Ian,

Quoted 3 lines · On Friday 26 October 2012 13:25:01 Ian Campbell wrote:

Quoted 1 line

+build: ;

What does the ";" in this syntax do?

A Make trick to do (really) nothing:
<http://www.gnu.org/software/make/manual/html_node/Empty-Recipes.html#Empty-Recipes>

Sincerely
Philipp

The main difference over the the XEN version

is the addition of the stats
structure (used for retrieving stats from a running tapdisk), and the addition of the tapdisk_message_blkif struct, which is required for the user-space counterpart of blktap/blkback to communicate with tapdisk.

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:28
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message types and structures

Quoted 1 line · Thanos Makatos

The main difference over the the XEN version

what do you mean by "the XEN version"? Is there an existing version of this header somewhere?

Quoted 5 lines

is the addition of the stats
structure (used for retrieving stats from a running tapdisk), and the addition of the tapdisk_message_blkif struct, which is required for the user-space counterpart of blktap/blkback to communicate with

tapdisk.

Am I correct that the interface defined here is one which is private between the tapdisk processes and the supplied control tools, abstracted away via libblktapctl?

Quoted 3 lines

+/**
+ * Retrieves the human-readable representation of the type of the

message.

tools/blktap3/include/tapdisk-message.h line 174

Quoted 4 lines

+ */

tools/blktap3/include/tapdisk-message.h new file +3 -0

+static inline char *tapdisk_message_name(enum tapdisk_message_id id)
+{
+    switch (id) {

Would a static lookup table be nicer?

Ian.

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:33
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk control function prototypes

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:

tools/blktap3/include/tap-ctl.h line 73

Quoted 4 lines

tools/blktap3/include/tap-ctl.h new file +4 -0

+    /**
+     * for linked lists
+     */
+    TAILQ_ENTRY(tap_list) entry;

This file doesn't seem to include the necessary header to define this? (Perhaps it is indirectly included?)

Anyway, since I think this header is intended to be used by consumers of blktap (rather than internally) I think you need to namespace the macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its usages in tools/libxl/Makefile and extras/mini-os/Makefile to create local namespaced versions for libxl and mini-os.

Quoted 6 lines

Anyway, since I think this header is intended to be used by consumers of blktap (rather than internally) I think you need to namespace the macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its usages in tools/libxl/Makefile and extras/mini-os/Makefile to create local namespaced versions for libxl and mini-os.

Just out of curiosity, what are the benefits of namespacing the macros? Google doesn't give anything relevant.

In this file various file-system paths are specified, similar to the XEN blktap2. These defines need to be documented. Unused defines (i.e. IOCTLs) have been removed.

diff -r efb6b2844256 -r a17c7217bef2 tools/blktap3/include/blktap.h

tools/blktap3/include/blktap.h new file +32 -0

@@ -0,0 +1,85 @@
+/*
+ * FIXME this is the github blktap2 license.
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __BLKTAP_3_H__
+#define __BLKTAP_3_H__

tools/blktap3/include/blktap.h new file +10 -0

+#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
+#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-enospc"
+
+/*
+ * TODO Can these be supplied from somewhere else?
+ */
+#define likely(_cond)   __builtin_expect(!!(_cond), 1)
+#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
+
+/*

+ */

tools/blktap3/include/blktap.h new file +5 -0

+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#endif /* ARRAY_SIZE */
+
+#endif /* __BLKTAP_3_H__ */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:37
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap header file

tools/blktap3/include/blktap.h line 42

Quoted 4 lines

tools/blktap3/include/blktap.h new file +4 -0

+/*
+ * TODO Document what each define is.
+ */
+#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"

I thought there was no kernel side to blktap3?

Review

Quoted 2 lines

(quoted diff) +2 -0

+#define BLKTAP3_CONTROL_NAME                "blktap-control"
+#define BLKTAP3_CONTROL_DIR

"/var/run/"BLKTAP3_CONTROL_NAME

tools/blktap3/include/blktap.h

Quoted 4 lines

tools/blktap3/include/blktap.h new file +3 -0

+#define BLKTAP3_CONTROL_SOCKET              "ctl"
 
+#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
+#define BLKTAP3_RING_DEVICE

BLKTAP3_DIRECTORY"/blktap"

Likewise these two.

Review

Quoted 3 lines

(quoted diff) +2 -0

+#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
+#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-

enospc"

Quoted 16 lines

tools/blktap3/include/blktap.h new file +16 -0

+
+/*
+ * TODO Can these be supplied from somewhere else?
+ */
+#define likely(_cond)   __builtin_expect(!!(_cond), 1)
+#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
+
+/*
+ * FIXME taken from list.h
+ */
+#define containerof(_ptr, _type, _memb) \
+    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
+
+/*
+ * FIXME shouldn't these be supplied from somewhere?
+ */

Review

Quoted 2 lines

(quoted diff) +2 -0

+#define __printf(a, b) __attribute__((format(printf, a, b))) #define
+__scanf(_f, _a) __attribute__((format (scanf, _f, _a)))

These are all abstractions of gcc-isms (presumably to ease ports to other compilers). We generally don't bother with this sort of thing in the tools, although you can if you like. You might want to put into a compiler.h and add suitable #if like those in xen/include/xen/compiler.h.

Quoted 10 lines

tools/blktap3/include/blktap.h new file +9 -0

+
+#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_HEAD(dst, node, entry);
+
+#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_TAIL(dst, node, entry);
+

tools/blktap3/include/blktap.h line 79

Quoted 4 lines

tools/blktap3/include/blktap.h new file +4 -0

+/*
+ * TODO This is defined in xen/lib.h, use that instead of redefining
+it
+ * here.

xen/lib.h is a hypervisor internal header so isn't available to you here. I think it is fine to define your own (although it should be in a private header, not part of the libblktap API)

Quoted 12 lines

+ */

tools/blktap3/include/blktap.h new file +5 -0

+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) #endif /*
+ARRAY_SIZE */
+
+#endif /* __BLKTAP_3_H__ */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

tools/blktap3/control/tap-ctl-list.c new file +12 -0

+
+#include "tap-ctl.h"
+
+void tap_ctl_list_free(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return;
+}
+
+int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:37
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty implementation for the tap_ctl_list and tap_ctl_list_free functions

tools/blktap3/control/tap-ctl-list.c line 32

Quoted 3 lines · Thanos Makatos

tools/blktap3/control/tap-ctl-list.c new file +3 -0

+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif

I think the presence of config.h will be statically determined, wont it?

Quoted 18 lines

tools/blktap3/control/tap-ctl-list.c new file +12 -0

+
+#include "tap-ctl.h"
+
+void tap_ctl_list_free(__attribute__((__unused__)) struct
+tqh_tap_list *list) {
+    return;
+}
+
+int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list
+*list) {
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

tools/blktap3/control/Makefile new file +33 -0

+
+MAJOR = 1.0
+MINOR = 0
+LIBNAME = libblktapctl
+LIBSONAME = $(LIBNAME).so.$(MAJOR)
+
+override CFLAGS += \
+	-I ../include \
+	$(CFLAGS_xeninclude)
+
+CTL_OBJS = \
+		   tap-ctl-destroy.o \
+		   tap-ctl-create.o \
+		   tap-ctl-list.o
+
+CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
+
+OBJS = $(CTL_OBJS) tap-ctl.o
+PICS = $(CTL_PICS)
+
+LIB_STATIC = $(LIBNAME).a
+LIB_SHARED = $(LIBSONAME).$(MINOR)
+
+all: build
+
+build: $(LIB_STATIC) $(LIB_SHARED)
+
+$(LIBNAME).so: $(LIBSONAME)
+	ln -sf $< $@
+
+$(LIBSONAME): $(LIB_SHARED)
+	ln -sf $< $@
+

tools/blktap3/control/Makefile new file +10 -0

+	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
+	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
+	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
+
+clean:
+	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
+	rm -f $(LIBNAME).so $(LIBSONAME)
+	rm -f *~
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:41
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for compiling the blktap3 control library

tools/blktap3/control/Makefile

Quoted 5 lines · Thanos Makatos

This library will be used by libxl to create/destroy tapdisks.

diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile

tools/blktap3/control/Makefile new file +0 -0

+0100

tools/blktap3/control/Makefile line 4

Quoted 5 lines

tools/blktap3/control/Makefile new file +4 -0

@@ -0,0 +1,57 @@
+XEN_ROOT := $(CURDIR)/../../../
+include $(XEN_ROOT)/tools/Rules.mk
+
+LIBDIR ?= /usr/lib

This comes from configure via config/Tools.mk now.

Quoted 37 lines

tools/blktap3/control/Makefile new file +37 -0

+
+MAJOR = 1.0
+MINOR = 0
+LIBNAME = libblktapctl
+LIBSONAME = $(LIBNAME).so.$(MAJOR)
+
+override CFLAGS += \
+	-I ../include \
+	$(CFLAGS_xeninclude)
+
+CTL_OBJS = \
+		   tap-ctl-destroy.o \
+		   tap-ctl-create.o \
+		   tap-ctl-list.o
+
+CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
+
+OBJS = $(CTL_OBJS) tap-ctl.o
+PICS = $(CTL_PICS)
+
+LIB_STATIC = $(LIBNAME).a
+LIB_SHARED = $(LIBSONAME).$(MINOR)
+
+all: build
+
+build: $(LIB_STATIC) $(LIB_SHARED)
+
+$(LIBNAME).so: $(LIBSONAME)
+	ln -sf $< $@
+
+$(LIBSONAME): $(LIB_SHARED)
+	ln -sf $< $@
+
+$(LIB_STATIC): $(CTL_OBJS)
+	$(AR) r $@ $^
+
+$(LIB_SHARED): $(CTL_PICS)

tools/blktap3/control/Makefile line 47

Quoted 6 lines

tools/blktap3/control/Makefile new file +6 -0

+	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
+		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
+
+# TODO install in /usr/sbin?
+install: $(LIB_STATIC) $(LIB_SHARED)
+	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)

Was this intended to be LIBDIR? At least until the TODO is resolved.

Quoted 16 lines

tools/blktap3/control/Makefile new file +10 -0

+	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
+	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
+	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
+
+clean:
+	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
+	rm -f $(LIBNAME).so $(LIBSONAME)
+	rm -f *~
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 6 lines

tools/blktap3/control/Makefile line 47

Quoted 4 lines

tools/blktap3/control/Makefile new file +4 -0

+
+# TODO install in /usr/sbin?
+install: $(LIB_STATIC) $(LIB_SHARED)
+	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)

Was this intended to be LIBDIR? At least until the TODO is resolved.

I'm confused, Which one?

Quoted 3 lines

Quoted 3 lines

tools/blktap3/control/Makefile new file +3 -0

+	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
+	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
+	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)

Provide implementation for the libxl__blktap_devpath and libxl__device_destroy_tapdisk functions: the former spawns the tapdisk process, the latter destroys it. Both of these functions use the blktap_find function, a function that lists all running tapdisks and looks for one serving a specific file. Finally, link libxl with the blktap3 control library.

diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile

tools/libxl/Makefile +0 -0

 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 
 libxenlight.a: $(LIBXL_OBJS)

diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +14 -2

 
-int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
-    return -ENOSYS;
+/**
+ * Creates a tapdisk for the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param disk
+ * @param format
+ *
+ * @returns 0 on success, an error code otherwise
+ */
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format)
+{

What if somebody

tools/libxl/libxl_blktap3.c +10 -0

+     * manually attaches a tapdisk to this path?
+     */
+    if (!(err = blktap_find(gc, type, disk, &tap))) {
+        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid, disk);
+        return 0;
+    }
+
+    LOG(DEBUG, "tapdisk not found\n");
+
+    /*

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:46
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement libxl__blktap_devpath and libxl__device_destroy_tapdisk

Quoted 2 lines · Thanos Makatos

Provide implementation for the libxl__blktap_devpath and libxl__device_destroy_tapdisk functions: the former spawns the

tapdisk

Quoted 3 lines

process, the latter destroys it. Both of these functions use the blktap_find function, a function that lists all running tapdisks and looks for one serving a specific file. Finally, link libxl with the

blktap3 control library.

Quoted 6 lines

diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile

tools/libxl/Makefile +0 -0

@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
 

tools/libxl/Makefile LIBUUID_LIBS += -luuid endif · line 25

Quoted 6 lines

tools/libxl/Makefile +3 -1

 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
 $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
+$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+$(LDLIBS_libblktapctl)

Is this adding back the thing I commented on earlier?

tools/libxl/Makefile CFLAGS_LIBXL += $(CFLAGS_libblktapctl) · line 34

Quoted 10 lines

tools/libxl/Makefile +4 -1

 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -29,7 +29,9 @@ CFLAGS_LIBXL
+= $(CFLAGS_libblktapctl)  CFLAGS_LIBXL += -Wshadow
 
 CFLAGS += $(PTHREAD_CFLAGS)
-LDFLAGS += $(PTHREAD_LDFLAGS)
+override LDFLAGS += \
+	$(PTHREAD_LDFLAGS) \
+	-L $(XEN_BLKTAP3)/control

Please (defined and) use LDLIBS_libblktapctl. Also this change to use override looks very dubious to me -- what does it do?

Quoted 6 lines

LIBXL_LIBS += $(PTHREAD_LIBS)

LIBXLU_LIBS =

tools/libxl/Makefile +0 -0

@@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
 	ln -sf $< $@
 

tools/libxl/Makefile libxenlight.so.$(MAJOR): libxenlight.so. · line 177

Quoted 2 lines

tools/libxl/Makefile +1 -0

 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
+	make -C $(XEN_BLKTAP3)

This shouldn't be needed if the tools/Makefile has things ordered correctly. It is reasonable for tools/libxl to assume that its prerequisites are already built. People who build with make -C tools/libxl need to take care of this themself.

tools/libxl/libxl_blktap3.c

Quoted 10 lines

tools/libxl/Makefile +0 -0

 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR)
 $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 

libxenlight.a: $(LIBXL_OBJS)
diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c

tools/libxl/libxl_blktap3.c +0 -1

 
-int libxl__device_destroy_tapdisk(libxl__gc *gc, const char

*be_path) {

Quoted 18 lines

tools/libxl/libxl_blktap3.c +17 -1

-    return -ENOSYS;
+/**
+ * Creates a tapdisk for the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param disk
+ * @param format
+ *
+ * @returns 0 on success, an error code otherwise  */ int
+libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format)
+{
+    const char *type = NULL;
+    char *params = NULL;
+    struct tap_list tap;
+    int err = 0;

tools/libxl/libxl_blktap3.c

Quoted 6 lines

tools/libxl/libxl_blktap3.c +6 -0

+
+    type = libxl__device_disk_string_of_format(format);
+
+    /*
+     * Ensure that no other tapdisk is serving this path.
+     * XXX Does libxl protect us against race conditions?

Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

tools/libxl/libxl_blktap3.c

Quoted 6 lines

What if somebody

tools/libxl/libxl_blktap3.c +4 -0

+     * manually attaches a tapdisk to this path?
+     */
+    if (!(err = blktap_find(gc, type, disk, &tap))) {
+        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid,

disk);

Quoted 11 lines

tools/libxl/libxl_blktap3.c +11 -0

+        return 0;
+    }
+
+    LOG(DEBUG, "tapdisk not found\n");
+
+    /*
+     * TODO Should we worry about return codes other than ENOENT?
+     */
+
+    params = libxl__sprintf(gc, "%s:%s", type, disk);
+    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {

tools/libxl/libxl_blktap3.c line 114

Quoted 5 lines

tools/libxl/libxl_blktap3.c +5 -0

+        LOG(DEBUG, "created tapdisk\n");
+        return 0;
+    }
+
+    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));

You can use LOGE or LOGEV here to get the errno type thing printed automatically in a consistent way.

Ian.

Quoted 6 lines

Quoted 6 lines

LIBXL_LIBS += $(PTHREAD_LIBS)

LIBXLU_LIBS =

tools/libxl/Makefile +0 -0

@@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
 	ln -sf $< $@
 

Quoted 7 lines

tools/libxl/Makefile libxenlight.so.$(MAJOR): libxenlight.so. · line 177

Quoted 2 lines

tools/libxl/Makefile +1 -0

 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
+	make -C $(XEN_BLKTAP3)

This shouldn't be needed if the tools/Makefile has things ordered correctly. It is reasonable for tools/libxl to assume that its prerequisites are already built. People who build with make -C tools/libxl need to take care of this themself.

I've added this so I can build libxl from within tools/libxl without worrying about building tools/blktap3, it simplifies development, doesn't it?

Quoted 7 lines

Quoted 7 lines

tools/libxl/libxl_blktap3.c +7 -0

+libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format)
+{
+    const char *type = NULL;
+    char *params = NULL;
+    struct tap_list tap;
+    int err = 0;

Quoted 8 lines

tools/libxl/libxl_blktap3.c

Quoted 6 lines

tools/libxl/libxl_blktap3.c +6 -0

+
+    type = libxl__device_disk_string_of_format(format);
+
+    /*
+     * Ensure that no other tapdisk is serving this path.
+     * XXX Does libxl protect us against race conditions?

Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

I don't think so, I'll have a look. This could be a problem if two guest VMs are created at the same time and they both use the same VDI, obviously a corner case. Should we protect against that or we're getting paranoid?

-----Original Message-----
From: Ian Campbell [mailto:[email protected]]
Sent: 30 October 2012 11:26
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement libxl__blktap_devpath and libxl__device_destroy_tapdisk

Quoted 14 lines

Quoted 13 lines

tools/libxl/Makefile libxenlight.so.$(MAJOR): libxenlight.so. · line 177

Quoted 8 lines

LIBXL_LIBS += $(PTHREAD_LIBS)

LIBXLU_LIBS =

tools/libxl/Makefile +1 -0

@@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
 	ln -sf $< $@
 
 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
+	make -C $(XEN_BLKTAP3)

This shouldn't be needed if the tools/Makefile has things ordered correctly. It is reasonable for tools/libxl to assume that its prerequisites are already built. People who build with make -C tools/libxl need to take care of this themself.

Quoted 3 lines

I've added this so I can build libxl from within tools/libxl without worrying about building tools/blktap3, it simplifies development, doesn't it?

If we did this for everything our Makefiles would be an unholy mess. Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry this patch locally.

Quoted 16 lines

Quoted 15 lines

tools/libxl/libxl_blktap3.c

Quoted 13 lines

tools/libxl/libxl_blktap3.c +12 -0

+libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format) {
+    const char *type = NULL;
+    char *params = NULL;
+    struct tap_list tap;
+    int err = 0;
+
+    type = libxl__device_disk_string_of_format(format);
+
+    /*
+     * Ensure that no other tapdisk is serving this path.
+     * XXX Does libxl protect us against race conditions?

Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

Quoted 2 lines

I don't think so, I'll have a look. This could be a problem if two guest VMs are created at the same time and they both use the same

VDI,

Quoted 2 lines

obviously a corner case. Should we protect against that or we're getting paranoid?

TBH I'm not sure what the semantics of sharing these things are supposed to be.

Ian

This series introduces support for blktap3 in libxl and adds the basis of the blktap3 build system. There is no essential blktap3 functionality yet: all blktap3 functions are stubs and they will be implemented in later patches. This means that trying to use tap as the disk backend for a guest will make libxl complain since all of blktap3 functions return a failure error code. Most header files introduced in this series require some basic documentation. Finally, licenses need to be verified.

-----Original Message-----
From: Ian Campbell
Sent: 26 October 2012 12:15
To: Thanos Makatos
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3 and introduce the blktap3 build system

As it stands this series will break the build and/or xl functionality at various points. I recommend ordering them as:
* Stage 1: populate tools/blktap3, make it build with make -C tools/blktap3 (build breakage within tools/blktap3 doesn't matter during this stage)
* Stage 2: connect tools/blktap3 to the top-level build system, but don't use it anywhere yet. At this point tools/blktap3 must compile successfully.
* Third tranche: Patch libxl/xl etc to make them use blktap3 instead of blktap2.