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

[Kevin Wolf <kwolf@xxxxxxx>]

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