All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: xen-devel@lists.xensource.com, Kevin Wolf <kwolf@suse.de>
Subject: Re: [PATCH] blktap: qcow2 image format support
Date: Thu, 21 Feb 2008 12:47:52 +0000	[thread overview]
Message-ID: <20080221124752.GB30015@redhat.com> (raw)
In-Reply-To: <200802211007.14443.Christoph.Egger@amd.com>

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@suse.de> 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....

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

  parent reply	other threads:[~2008-02-21 12:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-21  8:49 [PATCH] blktap: qcow2 image format support Kevin Wolf
2008-02-21  8:57 ` Keir Fraser
2008-02-21  9:07   ` Christoph Egger
2008-02-21  9:32     ` Kevin Wolf
2008-02-21 12:47     ` Daniel P. Berrange [this message]
2008-02-21 17:18       ` Ian Jackson
2008-02-21  9:28   ` Kevin Wolf
2008-02-21  9:20     ` Keir Fraser
2008-02-21 10:31 ` Keir Fraser
2008-02-24  3:12   ` Kurt Hackel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080221124752.GB30015@redhat.com \
    --to=berrange@redhat.com \
    --cc=Christoph.Egger@amd.com \
    --cc=kwolf@suse.de \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.