From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKSbM-0003Yp-Q1 for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:08:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKSbG-0007QH-Q4 for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:08:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKSbG-0007QC-CP for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:08:06 -0500 Date: Mon, 3 Mar 2014 14:08:00 +0100 From: Kevin Wolf Message-ID: <20140303130800.GG4850@dhcp-200-207.str.redhat.com> References: <1392996248-26781-1-git-send-email-kwolf@redhat.com> <1392996248-26781-4-git-send-email-kwolf@redhat.com> <53146AC8.1020807@dlhnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53146AC8.1020807@dlhnet.de> Subject: Re: [Qemu-devel] [PATCH v3 3/6] qemu-img convert: Support multiple -o options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 03.03.2014 um 12:43 hat Peter Lieven geschrieben: > On 21.02.2014 16:24, Kevin Wolf wrote: > >Instead of ignoring all option values but the last one, multiple -o > >options now have the same meaning as having a single option with all > >settings in the order of their respective -o options. > > > >Signed-off-by: Kevin Wolf > >--- > > qemu-img.c | 34 +++++++++++++++++++++++++--------- > > 1 file changed, 25 insertions(+), 9 deletions(-) > > > >diff --git a/qemu-img.c b/qemu-img.c > >index 9c1643d..3fd2168 100644 > >--- a/qemu-img.c > >+++ b/qemu-img.c > >@@ -1164,6 +1164,9 @@ static int img_convert(int argc, char **argv) > > Error *local_err = NULL; > > QemuOpts *sn_opts = NULL; > >+ /* Initialize before goto out */ > >+ qemu_progress_init(progress, 1.0); > >+ > moving this up here breaks progrss output because progress is always false > at this point. Meh. You're right, of course, this was a stupid one. I wonder if -p output is consistent enough that we can make a qemu-iotests case for it. At the moment I can't see a reason why it wouldn't be consistent. Kevin