All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qed: add qed-tool.py image manipulation utility
Date: Fri, 02 Dec 2011 12:13:31 +0100	[thread overview]
Message-ID: <4ED8B2DB.5050307@redhat.com> (raw)
In-Reply-To: <CAJSP0QXDK=G1UR_4SOGO1UUsRphQ8Hx7z2auO5A1c80+Yy9ivA@mail.gmail.com>

Am 02.12.2011 11:23, schrieb Stefan Hajnoczi:
> On Fri, Dec 2, 2011 at 9:15 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 01.12.2011 18:00, schrieb Stefan Hajnoczi:
>>> The qed-tool.py utility can inspect and manipulate QED image files.  It
>>> can be used for testing to see the state of image metadata and also to
>>> inject corruptions into the image file.  It also has a scrubbing feature
>>> to copy just the metadata out of an image file, allowing users to share
>>> broken image files without revealing data in bug reports.
>>>
>>> This has lived in my local repo for a long time but could be useful to
>>> others.
>>>
>>> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>>
>> For most of the commands, I think qemu-img/qemu-io should be extended
>> instead of creating scripts for one or two formats and lacking the
>> functionality for the rest.
> 
> I have mixed feelings about that because I don't think a common
> interface will ever live up to its promise.  We will have an interface
> that no two file formats implement much of (i.e. lots of NULL function
> pointers).  The user experience will be that these commands don't work
> ("Operation not supported") and it's more flexible (and less code) to
> write a format-specific script like this.
> 
> Also, usually before I use any of these potentially destructive
> commands I review the script's code to double-check exactly what the
> impact on the file will be.  It's nice to have a concise Python script
> that can be reviewed easily rather than looking through layers of
> production C code.
> 
> Do you really think there is much worth making common here?

Ok, I had another, closer look and there are two functions that I would
prefer to see in qemu-img info, namely fragmentation and dirty flag
status. For the rest you're probably right that an external script makes
more sense.

Kevin

  reply	other threads:[~2011-12-02 11:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 17:00 [Qemu-devel] [PATCH] qed: add qed-tool.py image manipulation utility Stefan Hajnoczi
2011-12-02  9:15 ` Kevin Wolf
2011-12-02 10:23   ` Stefan Hajnoczi
2011-12-02 11:13     ` Kevin Wolf [this message]
2011-12-02 13:31       ` Stefan Hajnoczi

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=4ED8B2DB.5050307@redhat.com \
    --to=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.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.