From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-user+bounces-133537-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1Rjglg-000263-Vx
	for garchives@archives.gentoo.org; Sun, 08 Jan 2012 00:37:49 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 55B8921C03F;
	Sun,  8 Jan 2012 00:37:34 +0000 (UTC)
Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212])
	by pigeon.gentoo.org (Postfix) with ESMTP id 9600F21C021
	for <gentoo-user@lists.gentoo.org>; Sun,  8 Jan 2012 00:36:22 +0000 (UTC)
Received: from mail-we0-f181.google.com ([74.125.82.181])
	by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.69)
	(envelope-from <pandu@poluan.info>)
	id 1RjgkI-001MRS-0L
	for gentoo-user@lists.gentoo.org; Sun, 08 Jan 2012 07:36:22 +0700
Received: by werm12 with SMTP id m12so2410629wer.40
        for <gentoo-user@lists.gentoo.org>; Sat, 07 Jan 2012 16:36:18 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.180.88.229 with SMTP id bj5mr15797024wib.5.1325982978397; Sat,
 07 Jan 2012 16:36:18 -0800 (PST)
Received: by 10.223.83.12 with HTTP; Sat, 7 Jan 2012 16:36:18 -0800 (PST)
Received: by 10.223.83.12 with HTTP; Sat, 7 Jan 2012 16:36:18 -0800 (PST)
In-Reply-To: <CA+czFiCx48uUVD0k2r8v4dddcDtDPKaLNZyRqn8Ejm9Di3CZkQ@mail.gmail.com>
References: <1325937084.37030@rumba>
	<4F084B8B.4080104@persimplex.net>
	<CAA2qdGVaPRBo59+RxKfU3sWY11AmWSzsgBfgnLt2z0719Yc8Tg@mail.gmail.com>
	<CA+czFiCx48uUVD0k2r8v4dddcDtDPKaLNZyRqn8Ejm9Di3CZkQ@mail.gmail.com>
Date: Sun, 8 Jan 2012 07:36:18 +0700
Message-ID: <CAA2qdGXvDos92u_+8Oj70QKD+4EFT8Szfi4Vy95sQfbp7B=udA@mail.gmail.com>
Subject: Re: [gentoo-user] gentoo-sources and xen blktap driver?
From: Pandu Poluan <pandu@poluan.info>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=f46d0442674067d58a04b5f97875
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com
X-AntiAbuse: Original Domain - lists.gentoo.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - poluan.info
X-Archives-Salt: 0e684c9b-4d79-4b2b-b3f2-ecd0fd177447
X-Archives-Hash: 27013ecc6d14466a50f793a4cd9deb74

--f46d0442674067d58a04b5f97875
Content-Type: text/plain; charset=UTF-8

On Jan 8, 2012 12:43 AM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Sat, Jan 7, 2012 at 11:35 AM, Pandu Poluan <pandu@poluan.info> wrote:
> > On Jan 7, 2012 8:44 PM, "victor romanchuk" <rom@persimplex.net> wrote:
> >>
> >> Konstantinos Agouros wrote, at 01/07/2012 03:51 PM:
> >> > since xen got into the mainstream kernel the way to go is to use
> >> > gentoo-sources for dom0 and the domUs. However the blktap modules are
> >> > not
> >> > there. Is there any way to get this to work?
> >>
> >> blktap drivers were excluded from kernel mainline since 3.x, these two
> >> threads
> >> from xen-users mailing list might put some light in that context:
> >>
> >>
> >>
http://old-list-archives.xen.org/archives/html/xen-users/2011-07/msg00637.html
> >>
> >>
http://old-list-archives.xen.org/archives/html/xen-users/2011-10/msg00065.html
> >>
> >> the latest sys-kernel/xen-sources containing working blktap (not
blktap2)
> >> is
> >> 2.6.38 (this is buggy from my point of view; i'm still sitting on
> >> 2.6.34-r5 for
> >> production installations)
> >>
> >
> > Can someone shed a light on the importance of blktap, i.e., why one
would
> > want to use it when -- as someone explained in the first email thread
you
> > gave -- blkfront+blkend is enough for paravirtualization?
>
> Reading through the linked threads, it sounds like the benefit stems
> from being able to shim things in between the front and back ends.
>
> You might want that for any number of reasons:
> * a block encryption layer
> * a metering layer
> * a read/write masking layer
> * an intercept to have the block device exist on (or be mirrored to)
> on another system.
>
> etc.
>

Ah yes, of course.

One of the threads also mentioned that blktap might be better implemented
in userspace.

Rgds,

--f46d0442674067d58a04b5f97875
Content-Type: text/html; charset=UTF-8

<p><br>
On Jan 8, 2012 12:43 AM, &quot;Michael Mol&quot; &lt;<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sat, Jan 7, 2012 at 11:35 AM, Pandu Poluan &lt;<a href="mailto:pandu@poluan.info">pandu@poluan.info</a>&gt; wrote:<br>
&gt; &gt; On Jan 7, 2012 8:44 PM, &quot;victor romanchuk&quot; &lt;<a href="mailto:rom@persimplex.net">rom@persimplex.net</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Konstantinos Agouros wrote, at 01/07/2012 03:51 PM:<br>
&gt; &gt;&gt; &gt; since xen got into the mainstream kernel the way to go is to use<br>
&gt; &gt;&gt; &gt; gentoo-sources for dom0 and the domUs. However the blktap modules are<br>
&gt; &gt;&gt; &gt; not<br>
&gt; &gt;&gt; &gt; there. Is there any way to get this to work?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; blktap drivers were excluded from kernel mainline since 3.x, these two<br>
&gt; &gt;&gt; threads<br>
&gt; &gt;&gt; from xen-users mailing list might put some light in that context:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; <a href="http://old-list-archives.xen.org/archives/html/xen-users/2011-07/msg00637.html">http://old-list-archives.xen.org/archives/html/xen-users/2011-07/msg00637.html</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; <a href="http://old-list-archives.xen.org/archives/html/xen-users/2011-10/msg00065.html">http://old-list-archives.xen.org/archives/html/xen-users/2011-10/msg00065.html</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; the latest sys-kernel/xen-sources containing working blktap (not blktap2)<br>
&gt; &gt;&gt; is<br>
&gt; &gt;&gt; 2.6.38 (this is buggy from my point of view; i&#39;m still sitting on<br>
&gt; &gt;&gt; 2.6.34-r5 for<br>
&gt; &gt;&gt; production installations)<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; Can someone shed a light on the importance of blktap, i.e., why one would<br>
&gt; &gt; want to use it when -- as someone explained in the first email thread you<br>
&gt; &gt; gave -- blkfront+blkend is enough for paravirtualization?<br>
&gt;<br>
&gt; Reading through the linked threads, it sounds like the benefit stems<br>
&gt; from being able to shim things in between the front and back ends.<br>
&gt;<br>
&gt; You might want that for any number of reasons:<br>
&gt; * a block encryption layer<br>
&gt; * a metering layer<br>
&gt; * a read/write masking layer<br>
&gt; * an intercept to have the block device exist on (or be mirrored to)<br>
&gt; on another system.<br>
&gt;<br>
&gt; etc.<br>
&gt;</p>
<p>Ah yes, of course.</p>
<p>One of the threads also mentioned that blktap might be better implemented in userspace.</p>
<p>Rgds,<br>
</p>

--f46d0442674067d58a04b5f97875--