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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] blktap: qcow2 image format support

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] blktap: qcow2 image format support
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Thu, 21 Feb 2008 17:18:16 +0000
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Kevin Wolf <kwolf@xxxxxxx>
Delivery-date: Fri, 22 Feb 2008 07:44:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080221124752.GB30015@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <C3E2ED8C.1430F%Keir.Fraser@xxxxxxxxxxxx> <200802211007.14443.Christoph.Egger@xxxxxxx> <20080221124752.GB30015@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Daniel P. Berrange writes ("Re: [Xen-devel] [PATCH] blktap: qcow2 image format 
> Well if you're concerned about code duplication - we've 2 entirely
> separate impls of every disk format - one in blktap and one in QEMU
> itself. The original motivation for the duplication was that QEMU's
> block driver API did not support Async-IO operations, but that was
> addressed in 0.9.0 - if you look at the internal QEMU block driver
> API for disk formats vs blktaps internal driver API they're near
> identical.

Yes.  This is pretty poor and although I don't want to stand in the
way of useful stuff I'm disappointed to see more of this duplication
going on.

>  I think it'd be an interesting project to actually make
> QEMU userspace talk directly to blktap kernel driver, thus eliminating
> the entire blktap users & all code duplication. Then we'd have parity
> of disk support across PV & HVM guests too. Certainly not an easy or
> quick project, but if someone's looking for something interesting to
> hack on....

I'm currently trying to merge our qemu with upstream's, at least
somewhat, and this is definitely something I'm keeping an eye on.


Xen-devel mailing list