From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQaW-0007bZ-M9 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:33:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBQaO-0000kH-GS for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:33:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQaO-0000k4-8P for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:33:04 -0400 Message-ID: <504F3D75.3080100@redhat.com> Date: Tue, 11 Sep 2012 15:32:37 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1343127865-16608-1-git-send-email-pbonzini@redhat.com> <1343127865-16608-22-git-send-email-pbonzini@redhat.com> In-Reply-To: <1343127865-16608-22-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 21/47] block: add bdrv_ensure_backing_file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: jcody@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Am 24.07.2012 13:03, schrieb Paolo Bonzini: > Mirroring runs without the backing file so that it can be copied outside > QEMU. However, we need to add it at the time the job is completed and > QEMU switches to the target. Factor out the common bits of opening an > image and completing a mirroring operation. > > Signed-off-by: Paolo Bonzini Once again, combining code motion and code changes in one patch makes it harder to review. bdrv_ensure_backing_file() isn't a good name, after reading only the subject line I had no idea what this function might do. It's still not entirely clear to me what the different to a bdrv_open_backing_file() is, except that it doesn't do anything if a backing file is already open. In which cases do we rely on this behaviour? > --- > block.c | 69 ++++++++++++++++++++++++++++++++++++++++----------------------- > block.h | 1 + > 2 files changed, 45 insertions(+), 25 deletions(-) > > diff --git a/block.c b/block.c > index 19da114..002b442 100644 > --- a/block.c > +++ b/block.c > @@ -730,6 +730,48 @@ int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags) > return 0; > } > > +int bdrv_ensure_backing_file(BlockDriverState *bs) > +{ > + char backing_filename[PATH_MAX]; > + int back_flags, ret; > + BlockDriver *back_drv = NULL; > + > + if (bs->backing_hd != NULL) { > + return 0; > + } > + > + bs->open_flags &= ~BDRV_O_NO_BACKING; This doesn't do anything in this patch because the function is never called with BDRV_O_NO_BACKING set. Is it in preparation for a second user? > + if (bs->backing_file[0] == '\0') { > + return 0; > + } > + > + bs->backing_hd = bdrv_new(""); > + bdrv_get_full_backing_filename(bs, backing_filename, > + sizeof(backing_filename)); > + > + if (bs->backing_format[0] != '\0') { > + back_drv = bdrv_find_format(bs->backing_format); > + } > + > + /* backing files always opened read-only */ > + back_flags = bs->open_flags & ~(BDRV_O_RDWR | BDRV_O_SNAPSHOT); > + > + ret = bdrv_open(bs->backing_hd, backing_filename, back_flags, back_drv); > + if (ret < 0) { > + bdrv_close(bs); I don't like this because it makes the invalid assumption that the caller has just opened bs and wants to close it if opening the backing file fails. I think this is part of the error handling that belongs in the caller: It opened bs, so it is responsible for closing it in error cases. > + bdrv_delete(bs->backing_hd); This is a bug fix of its own, should be a separate patch. > + bs->backing_hd = NULL; > + return ret; > + } > + if (bs->is_temporary) { > + bs->backing_hd->keep_read_only = !(bs->open_flags & BDRV_O_RDWR); > + } else { > + /* base images use the same setting as leaf */ Huh, "parent" turned into "leaf"? > + bs->backing_hd->keep_read_only = bs->keep_read_only; > + } > + return 0; > +} Kevin