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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 4/11/08 10:05, "Kevin Wolf" <kwolf@xxxxxxx> wrote:

>> 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?

Yes, it does seem to me that blktap2 world and qemu-tap world can coexist
quite happily. As long as both camps have supporters and are maintained,
what's the problem? I don't think these email arguments are changing
anyone's entrenched positions.

 -- Keir



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