All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Fam Zheng <famcool@gmail.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, hch@lst.de
Subject: Re: [Qemu-devel] [PATCH v8 00/12] Adding VMDK monolithic flat support
Date: Fri, 8 Jul 2011 16:40:59 +0100	[thread overview]
Message-ID: <CAJSP0QVL9qHZE3Y4j0JXiCk1VfpJXmxanz7NJf3mnw+Qb1F4gA@mail.gmail.com> (raw)
In-Reply-To: <1309865478-32766-1-git-send-email-famcool@gmail.com>

On Tue, Jul 5, 2011 at 12:31 PM, Fam Zheng <famcool@gmail.com> wrote:
> Chnages from v7:
>    03/12: remove deadloop in probing descriptor file.
>
> Fam Zheng (12):
>  VMDK: introduce VmdkExtent
>  VMDK: bugfix, align offset to cluster in get_whole_cluster
>  VMDK: probe for monolithicFlat images
>  VMDK: separate vmdk_open by format version
>  VMDK: add field BDRVVmdkState.desc_offset
>  VMDK: flush multiple extents
>  VMDK: move 'static' cid_update flag to bs field
>  VMDK: change get_cluster_offset return type
>  VMDK: open/read/write for monolithicFlat image
>  VMDK: create different subformats
>  VMDK: fix coding style
>  block: add bdrv_get_allocated_file_size() operation
>
>  block.c           |   19 +
>  block.h           |    1 +
>  block/raw-posix.c |   21 +
>  block/raw-win32.c |   29 ++
>  block/vmdk.c      | 1361 +++++++++++++++++++++++++++++++++++++----------------
>  block_int.h       |    2 +
>  qemu-img.c        |   31 +--
>  7 files changed, 1024 insertions(+), 440 deletions(-)

Getting closer.  Patch 10/12 is big and I see a lot of repetition in
the image creation process.  I wonder if it helps to factor out
certain aspects such as filename and descriptor generation so that the
creation function doesn't become so large.  The aim is to encapsulate
aspects of image creation cleanly so that the caller doesn't need to
keep state around and can use a simple interface to orchestrate image
creation.

Structuring is going to be important for future vmdk changes.  We need
to introduce clean interfaces to separate subformats while keeping
common code shared as utility functions.  Right now there is a lot of
if (flat) { ... } or if (!strcmp(..., "monolithicSparse")) { ... }.
The details of various formats are spread throughout the entire vmdk
codebase instead of encapsulated in one module each.  This will become
even more important as you flesh out the support matrix for various
file formats.  Something to keep in mind for future work after this
series.

Stefan

      parent reply	other threads:[~2011-07-08 15:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05 11:31 [Qemu-devel] [PATCH v8 00/12] Adding VMDK monolithic flat support Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 01/12] VMDK: introduce VmdkExtent Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 02/12] VMDK: bugfix, align offset to cluster in get_whole_cluster Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 03/12] VMDK: probe for monolithicFlat images Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 04/12] VMDK: separate vmdk_open by format version Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 05/12] VMDK: add field BDRVVmdkState.desc_offset Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 06/12] VMDK: flush multiple extents Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 07/12] VMDK: move 'static' cid_update flag to bs field Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 08/12] VMDK: change get_cluster_offset return type Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 09/12] VMDK: open/read/write for monolithicFlat image Fam Zheng
2011-07-08 12:55   ` Stefan Hajnoczi
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 10/12] VMDK: create different subformats Fam Zheng
2011-07-08 15:29   ` Stefan Hajnoczi
2011-07-09 12:09     ` Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 11/12] VMDK: fix coding style Fam Zheng
2011-07-05 11:31 ` [Qemu-devel] [PATCH v8 12/12] block: add bdrv_get_allocated_file_size() operation Fam Zheng
2011-07-08 15:40 ` Stefan Hajnoczi [this message]

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=CAJSP0QVL9qHZE3Y4j0JXiCk1VfpJXmxanz7NJf3mnw+Qb1F4gA@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=famcool@gmail.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.