WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [4 Patches] New blktap implementation, 2nd try

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: Re: [Xen-devel] [4 Patches] New blktap implementation, 2nd try
From: Kevin Wolf <kwolf@xxxxxxx>
Date: Tue, 04 Nov 2008 11:05:10 +0100
Cc: Dutch Meyer <dmeyer@xxxxxxxxx>, Andrew Warfield <andy@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 04 Nov 2008 02:02:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49101956.3080205@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <Pine.GSO.4.60.0810310026340.13665@xxxxxxxxxxxxxxxxx> <490ADA76.9010800@xxxxxxx> <Pine.GSO.4.60.0810311042190.885@xxxxxxxxxxxxxxxxx> <490ED94B.7050304@xxxxxxx> <49101956.3080205@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.17 (X11/20080922)
Gerd Hoffmann schrieb:
> Kevin Wolf wrote:
>> So what I'm saying is that while I'm not opposed to a rewrite in
>> principle, the rewrite needs to be a complete drop-in replacement to
>> avoid this third copy of the code. Ideally the rewrite would be
>> completely integrated into qemu, but at least not having a third copy
>> and making things even worse is a must, IMHO.
> 
> Oh, btw:  qemu itself will get a xen block backend implementation soon
> anyway.
> 
> [...] 
> 
> Note that a special kernel driver for blktap isn't needed at all.  You
> can simply use the generic grant table and event channel device drivers.
>    Which is exactly what the qemu backend implementation does.  IMHO the
> blktap kernel driver is there only for historical reasons (it predates
> gntdev) and it should go away long-term.

Sorry, Gerd, I should have copied you from the beginning.

I agree that integrating the backend into qemu is the right thing. You
don't want to have numerous tools running. It's not a complete solution,
though. A nice thing about blktap is that you can attach a qcow2 image
to Dom0, e.g. to copy the kernel out of the image.

I think this is the point where your approach and the new blktap (which
according to Andraw in fact isn't blktap anymore) are complementary.
blkfront talks to qemu which uses its drivers to access the image.
Alternatively (maybe for the more complicated stuff blktap seems to
provide) it can use the now Xen agnostic blktap to access the blktap
device nodes through its raw block driver. For accessing images in Dom0,
blktap without qemu is used. And of course, the blktap drivers are
compiled out of qemu source if qemu has the respective driver.

Does that sound reasonable?

> The qemu block layer has some problems performance-wise, so I can see
> your reasons to not use qemu.  And the qemu backend will most likely not
> (yet) match blktap performance-wise.  Nevertheless I think time is
> better spent fixing these problems in upstream qemu instead of forking
> off the qemu block layer code for the tapdisk daemon.

qemu didn't perform that bad in my tests. blkbk is faster, of course,
but it's not by orders of magnitude. But you're right in that Xen should
finally learn to work with upstream instead of forking everything (and
Ian's merging work was a great start - but still just a start).

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel