From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWR0h-00082p-J1 for qemu-devel@nongnu.org; Fri, 02 Dec 2011 06:10:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWR0b-0007Wu-K3 for qemu-devel@nongnu.org; Fri, 02 Dec 2011 06:10:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWR0b-0007Wa-7q for qemu-devel@nongnu.org; Fri, 02 Dec 2011 06:10:25 -0500 Message-ID: <4ED8B2DB.5050307@redhat.com> Date: Fri, 02 Dec 2011 12:13:31 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1322758843-19809-1-git-send-email-stefanha@linux.vnet.ibm.com> <4ED89742.1060003@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qed: add qed-tool.py image manipulation utility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel@nongnu.org Am 02.12.2011 11:23, schrieb Stefan Hajnoczi: > On Fri, Dec 2, 2011 at 9:15 AM, Kevin Wolf 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 >> >> 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