[Xen-devel] [PATCH 00 of 15 v4] blktap3: Introduce a small subset of blktap3 files

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

blktap3 is a disk back-end driver. It is based on blktap2 but does not require
the blktap/blkback kernel modules as it allows tapdisk to talk directly to
blkfront. This primarily simplifies maintenance, and _may_ lead to performance
improvements. blktap3 is based on a blktap2 fork maintained mostly by Citrix
(it lives in github), so these changes are also imported, apart from the
blktap3 ones.

I've organised my upstream effort as follows:
1. Upstream the smallest possible subset of blktap3 that will allow guest VMs
   to use RAW images backed by blktap3. This will enable early testing on the
   bits introduced by blktap3.
2. Upstream the remaining of blktap3, most notably back-end drivers, e.g. VHD
   etc.
3. Import bug fixes from blktap2 living in github.
4. Import new features and optimisations from blktap2 living in github, e.g.
   the mirroring plug-in.
blktap3 is broken into patches that can be found here:
https://bitbucket.org/tmakatos/blktap3-patches

blktap3 is made of the following components:
1. blkfront (not a blktap3 component and already upstream): a virtual block
   device driver in the guest VM that receives block I/O requests and forwards
   them to tapdisk via the shared ring.
2. tapdisk: a user space process that receives block I/O requests from
   blkfront, translates them to whatever the current backing file format is
   (i.e. RAW, VHD, qcow etc.), and performs the actual I/O. Apart from block
   I/O requests, the tapdisk also allows basic management of each virtual block
   device, e.g. a device may be temporarily paused. tapdisk listens to a
   loopback socket for such commands. The tap-ctl utility (explained later) can
   be used for managing the tapdisk.
3. tapback (formerly known as xenio): a user space daemon that acts as the
   back-end of each virtual block device: it monitors XenStore for the block
   front-end's state changes, creates/destroys the shared ring, spawns the
   tapdisk if necessary, and instructs the tapdisk to connect to/disconnect
   from the shared ring. It also communicates to the block front-end required
   parameters (e.g. block device size in sectors) via XenStore. The tapback
   daemon is only involved during the set up/tear down of the connection
   between the two ends, it does not participate in the data path. There is one
   tapback daemon per back-end driver domain, though we could have a tapback
   daemon per guest VM or per VBD.
5. libblktapctl: a user space library where the tapdisk management functions
   are implemented, used by libxl and the tapback daemon.
6. tap-ctl: a user space utility that allows management of the tapdisk, uses
  libblktapctl.

This patch series introduces a small subset of files required by tapback (the
tapback daemon is introduced by the next patch series):
- basic blktap3 header files
- a rudimentary implementation of libblktapctl. Only the bits required by
  tapback to manage the tapdisk are introduced, the rest of this library will
  be introduced by later patches.

Signed-off-by: Thanos Makatos <thanos.makatos@xxxxxxxxxx>

---
Changed since v1:
  * In all patches the patch message has been improved.
  * Patches 1, 5, and 6 use GPLv2.
  * Patch 0: Basic explanation of blktap3's fundamental components.
  * Patch 9: Improved tools/blktap3/control/Makefile by moving hard coded
    paths to config/StdGNU.mk.

Changed since v2:
  * Updated tapback daemon description.

Changed since v3:
  * Update description of blktap3 architecture.
  * Introduced additional tap-ctl-* files as a result of the architectural
    change.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel