[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Thanos Makatos <thanos.makatos@xxxxxxxxxx>
  • Date: Mon, 25 Feb 2013 11:15:52 +0000
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Delivery-date: Mon, 25 Feb 2013 11:16:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac36LT+yhLmLzV4IROil8b4+j4sbIQZHDCAg
  • Thread-topic: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of blktap3 files

Ping?

> -----Original Message-----
> From: Thanos Makatos [mailto:thanos.makatos@xxxxxxxxxx]
> Sent: 24 January 2013 12:21
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Thanos Makatos
> Subject: [PATCH 0 of 9 RFC v3] 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 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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.