Patch 3 of 3. Signed-off-by: Jake Wires <jake.wires@citrix.com>, Dutch Meyer <dmeyer@cs.ubc.ca> This is a new and rewritten version of blktap that we have developed at Citrix. The current version of blktap is left functionally unmodified. The change set consists of three patches. 0) A patch to deprecate the open source blktap, by moving it and issuing a warning whenever it is used. No functionality is modified in this patch, it is just housekeeping. 1) A patch to add a new blktap implementation that is feature equivalent to (or better than) the current open source blktap. This will eventually replace the current blktap implementation. 2) Fix several bugs in the qcow tools. 3) A kernel patch to add a new unified blktap2 module that will eventually replace blktap. The new blktap implementation has several improvements. * Isolation from xenstore - Blktap devices can now be created in dom0 as virtual block devices without coordination from xen and have few dependencies on xenstore in normal operation. * Improved development environment for tapdisks, simpler request forwarding, new request scheduler. * Pause scripts updated to support live qcow snapshot (see xmsnap script) * New tapdisk type: Block Mason disks allow a set of tapdisks to be flexibly arranged into graph structure and modified on-the-fly. Several example modules for Block Mason are included. Block Mason disks are constructed and modified with a declarative configuration language. These capabilities are discussed in more depth in an upcoming paper in the First Workshop on IO Virtualization, available HERE: http://www.cs.ubc.ca/~dmeyer/blockmason-wiov-final.pdf --Dutch _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31/10/08 03:16, "Dutch Meyer" <dmeyer@cs.ubc.ca> wrote:> 3) A kernel patch to add a new unified blktap2 module that will > eventually replace blktap.Is it necessary to keep old blktap kernel driver around for qemu''s tap implementation? Can the two drivers (old and new) coexist next to each other? If yes to both, can we at least get rid of the old one when Gerd''s qemu changes go in? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 31/10/08 03:16, "Dutch Meyer" <dmeyer@cs.ubc.ca> wrote: > >> 3) A kernel patch to add a new unified blktap2 module that will >> eventually replace blktap. > > Is it necessary to keep old blktap kernel driver around for qemu''s tap > implementation? Can the two drivers (old and new) coexist next to each > other?They don''t conflict all all, they can coesist exactly like blkback and blktap can coexist today. The qemu implementation uses another backend directory (blkback is ''vbd'', blktap is ''tap'', qemu is ''qdisk''). To be usable qdisk will need some windup in xend, so it either creates the xenstore entries needed or adds the approximate command line options when starting qemu-dm. So one can do a smooth switchover: (a) wait for it being merged, (b) do xend windup and test stuff, (c) fix bug if needed and (d) drop blktap once we are confident there are no regressions. cheers, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel