Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] gentoo-sources and xen blktap driver?
Date: Sun, 08 Jan 2012 00:44:18
Message-Id: CA+czFiBpyN5-ZZNuVgg0Gd4Cp5QWyLL=isWL_RVJdvE5Ygsq9g@mail.gmail.com
In Reply to: Re: [gentoo-user] gentoo-sources and xen blktap driver? by Pandu Poluan
1 On Sat, Jan 7, 2012 at 7:36 PM, Pandu Poluan <pandu@××××××.info> wrote:
2 > On Jan 8, 2012 12:43 AM, "Michael Mol" <mikemol@×××××.com> wrote:
3 >> On Sat, Jan 7, 2012 at 11:35 AM, Pandu Poluan <pandu@××××××.info> wrote:
4 >> > On Jan 7, 2012 8:44 PM, "victor romanchuk" <rom@××××××××××.net> wrote:
5 >> >>
6 >> >> Konstantinos Agouros wrote, at 01/07/2012 03:51 PM:
7 >> >> > since xen got into the mainstream kernel the way to go is to use
8 >> >> > gentoo-sources for dom0 and the domUs. However the blktap modules are
9 >> >> > not
10 >> >> > there. Is there any way to get this to work?
11 >> >>
12 >> >> blktap drivers were excluded from kernel mainline since 3.x, these two
13 >> >> threads
14 >> >> from xen-users mailing list might put some light in that context:
15 >> >>
16 >> >>
17 >> >>
18 >> >> http://old-list-archives.xen.org/archives/html/xen-users/2011-07/msg00637.html
19 >> >>
20 >> >>
21 >> >> http://old-list-archives.xen.org/archives/html/xen-users/2011-10/msg00065.html
22 >> >>
23 >> >> the latest sys-kernel/xen-sources containing working blktap (not
24 >> >> blktap2)
25 >> >> is
26 >> >> 2.6.38 (this is buggy from my point of view; i'm still sitting on
27 >> >> 2.6.34-r5 for
28 >> >> production installations)
29 >> >>
30 >> >
31 >> > Can someone shed a light on the importance of blktap, i.e., why one
32 >> > would
33 >> > want to use it when -- as someone explained in the first email thread
34 >> > you
35 >> > gave -- blkfront+blkend is enough for paravirtualization?
36 >>
37 >> Reading through the linked threads, it sounds like the benefit stems
38 >> from being able to shim things in between the front and back ends.
39 >>
40 >> You might want that for any number of reasons:
41 >> * a block encryption layer
42 >> * a metering layer
43 >> * a read/write masking layer
44 >> * an intercept to have the block device exist on (or be mirrored to)
45 >> on another system.
46 >>
47 >> etc.
48 >>
49 >
50 > Ah yes, of course.
51 >
52 > One of the threads also mentioned that blktap might be better implemented in
53 > userspace.
54
55 Well, there's that, too. For a while, there's been a long push in
56 Linux to get anything that could remotely reasonably be done in
57 userspace out of kernelspace.
58
59 --
60 :wq