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

Gerd Hoffmann schrieb:
>> 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.
> 
> There is qemu-nbd ...

Right, I forgot about that one.

>> 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.
> 
> Would work, yes.  But what is the point?  qemu will certainly not rip
> out the disk format drivers, so there is zero need to go that route.

Well, at the moment I for my part don't feel the need to go that route.
Neither do you. But obviously Andrew and Dutch do.

I don't know, maybe blktap2 really has some nice features that someone
might want to use. And if they maintain blktap2 - why not? If we make
the separation as I proposed (with the option of qemu-nbd instead of
blktap2 for attaching to Dom0), it doesn't hurt anyone after all - you
can use it then, but you're not forced.

Kevin

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