From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NaQvb-0001OH-3x for qemu-devel@nongnu.org; Thu, 28 Jan 2010 04:44:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NaQvW-0001NS-PW for qemu-devel@nongnu.org; Thu, 28 Jan 2010 04:44:42 -0500 Received: from [199.232.76.173] (port=46170 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaQvW-0001NP-KK for qemu-devel@nongnu.org; Thu, 28 Jan 2010 04:44:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:21058) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NaQWB-0002oK-Jq for qemu-devel@nongnu.org; Thu, 28 Jan 2010 04:18:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NaQW8-00074t-IN for qemu-devel@nongnu.org; Thu, 28 Jan 2010 04:18:25 -0500 Message-ID: <4B615622.8090902@redhat.com> Date: Thu, 28 Jan 2010 10:17:22 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Fix qemu-img can't create qcow image based on read-only image References: <1264656166-6360-1-git-send-email-sheng@linux.intel.com> In-Reply-To: <1264656166-6360-1-git-send-email-sheng@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sheng Yang Cc: kvm@vger.kernel.org, Marcelo Tosatti , qemu-devel@nongnu.org, Naphtali Sprei Am 28.01.2010 06:22, schrieb Sheng Yang: > Commit 03cbdac7 "Disable fall-back to read-only when cannot open drive's > file for read-write" result in read-only image can't be used as backed > image in qemu-img. > > CC: Naphtali Sprei > Signed-off-by: Sheng Yang > --- > > This issue blocked our QA's KVM nightly test. But in fact, I don't like this > patch, feeling uncomfortable to change long existed interface... Any > alternative? Add a readonly command line would change the default behavior(I > don't think fall back to readonly looks like a bug); or even revert the > commit? What's the story behind it? > > qemu-img.c | 15 ++++++++++----- > 1 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/qemu-img.c b/qemu-img.c > index 3cea8ce..f8be5cb 100644 > --- a/qemu-img.c > +++ b/qemu-img.c > @@ -188,11 +188,13 @@ static int read_password(char *buf, int buf_size) > #endif > > static BlockDriverState *bdrv_new_open(const char *filename, > - const char *fmt) > + const char *fmt, > + int readonly) > { > BlockDriverState *bs; > BlockDriver *drv; > char password[256]; > + int flags = BRDV_O_FLAGS; > > bs = bdrv_new(""); > if (!bs) > @@ -204,7 +206,10 @@ static BlockDriverState *bdrv_new_open(const char *filename, > } else { > drv = NULL; > } > - if (bdrv_open2(bs, filename, BRDV_O_FLAGS | BDRV_O_RDWR, drv) < 0) { > + if (!readonly) { > + flags |= BDRV_O_RDWR; > + } > + if (bdrv_open2(bs, filename, flags, drv) < 0) { > error("Could not open '%s'", filename); > } > if (bdrv_is_encrypted(bs)) { > @@ -343,7 +348,7 @@ static int img_create(int argc, char **argv) > } > } > > - bs = bdrv_new_open(backing_file->value.s, fmt); > + bs = bdrv_new_open(backing_file->value.s, fmt, 1); > bdrv_get_geometry(bs, &size); > size *= 512; > bdrv_delete(bs); > @@ -627,7 +632,7 @@ static int img_convert(int argc, char **argv) > > total_sectors = 0; > for (bs_i = 0; bs_i < bs_n; bs_i++) { > - bs[bs_i] = bdrv_new_open(argv[optind + bs_i], fmt); > + bs[bs_i] = bdrv_new_open(argv[optind + bs_i], fmt, 0); Shouldn't it be read-only here, too? Kevin