From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of blktap3 files
Date: Thu, 24 Jan 2013 12:20:40 +0000 [thread overview]
Message-ID: <patchbomb.1359030040@makatos-desktop> (raw)
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. libsring (formerly known as libxenio): a user space library that implements
the functionality required to access the shared ring. It is used by tapdisk
to obtain the block I/O requests forwarded by the front-end, and to produce
the corresponding responses. This is the very "heart" of blktap3, it's
architecture will be thoroughly explained by the patch series that
introduces it.
4. 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, 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. In this prototype, the tapdisk is spawned/destroyed by libxl when a
domain is created/destroyed, in the exact same way as in blktap2 (libxl
uses libblktapctl for this). When tapback detects a device creation request
from a front-end, it must locate the tapdisk (previously created by libxl)
designated to serve this VBD. There is no particular reason for this design,
we could as well have the tapback daemon spawning the tapdisk (the latter
choice looks neater IMO). Opting for the latter design wouldn't affect this
patch series that much.
5. libblktapctl: a user space library where the tapdisk management functions
are implemented, used by libxl and tap-ctl.
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.
---
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.
next reply other threads:[~2013-01-24 12:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-24 12:20 Thanos Makatos [this message]
2013-01-24 12:20 ` [PATCH 1 of 9 RFC v3] blktap3: Introduce blktap3 headers Thanos Makatos
2013-01-24 12:20 ` [PATCH 2 of 9 RFC v3] blktap3/libblktapctl: Introduce tapdisk message types and structures Thanos Makatos
2013-01-24 12:20 ` [PATCH 3 of 9 RFC v3] blktap3/libblktapctl: Introduce the tapdisk control header Thanos Makatos
2013-01-24 12:20 ` [PATCH 4 of 9 RFC v3] blktap3/libblktapctl: Introduce listing running tapdisks functionality Thanos Makatos
2013-01-24 12:20 ` [PATCH 5 of 9 RFC v3] blktap3/libblktapctl: Introduce functionality used by tapback to instruct tapdisk to connect to the sring Thanos Makatos
2013-01-24 12:20 ` [PATCH 6 of 9 RFC v3] blktap3/libblktapctl: Introduce block device control information retrieval functionality Thanos Makatos
2013-01-24 12:20 ` [PATCH 7 of 9 RFC v3] blktap3/libblktapctl: Introduce tapdisk message exchange functionality Thanos Makatos
2013-01-24 12:20 ` [PATCH 8 of 9 RFC v3] blktap3/libblktapctl: Introduce tapdisk spawn functionality Thanos Makatos
2013-01-24 12:20 ` [PATCH 9 of 9 RFC v3] blktap3/libblktapctl: Introduce makefile that builds tapback-required libblktapctl functionality Thanos Makatos
2013-02-25 11:15 ` [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of blktap3 files Thanos Makatos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=patchbomb.1359030040@makatos-desktop \
--to=thanos.makatos@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).