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: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] blktap: qcow2 image format support
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Thu, 21 Feb 2008 12:47:52 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Kevin Wolf <kwolf@xxxxxxx>
Delivery-date: Thu, 21 Feb 2008 04:48:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200802211007.14443.Christoph.Egger@xxxxxxx>
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>
References: <C3E2ED8C.1430F%Keir.Fraser@xxxxxxxxxxxx> <200802211007.14443.Christoph.Egger@xxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Feb 21, 2008 at 10:07:14AM +0100, Christoph Egger wrote:
> On Thursday 21 February 2008 09:57:48 Keir Fraser wrote:
> > On 21/2/08 08:49, "Kevin Wolf" <kwolf@xxxxxxx> wrote:
> > > This patch adds support for the qcow2 image format to blktap. It
> > > consists mostly of qemu code, adapted to the blktap interfaces.
> > > Snapshots and compressed images are supported.
> > >
> > > The qcow2 driver may be used by either specifying tap:qcow2 or by using
> > > tap:qcow which will detect that you have a version 2 image and will call
> > > the qcow2 driver.
> >
> > Is qcow2 so different from qcow1 that it really needs its own backend
> > driver?
> IMO, _all_ blktap drivers need some code refactoring. There is a lot of
> duplicated code across all drivers
> that can be moved into a blktap/drivers/blk-common.c.

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

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Xen-devel mailing list