Re: [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of blktap3 files

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

Ping?

> -----Original Message-----
> From: Thanos Makatos [mailto:thanos.makatos@xxxxxxxxxx]
> Sent: 04 December 2012 18:20
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Thanos Makatos
> Subject: [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of
> blktap3 files
> 
> 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 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. libtapback: 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 blkfront, 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: 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.
> 5. libblktapctl: a user space library where the tapdisk management
> functions
>    are implemented.
> 6. tap-ctl: a user space utility that allows management of the tapdisk,
> uses
>    libblktapctl.
> 
> 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.
> 
> 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.

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