From nobody Thu Dec 18 17:54:24 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1551110612677584.1560913735981; Mon, 25 Feb 2019 08:03:32 -0800 (PST) Received: from localhost ([127.0.0.1]:39661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyIj2-0000h0-IU for importer@patchew.org; Mon, 25 Feb 2019 11:03:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyI5T-0000zM-50 for qemu-devel@nongnu.org; Mon, 25 Feb 2019 10:22:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gyI5Q-0001XV-NJ for qemu-devel@nongnu.org; Mon, 25 Feb 2019 10:22:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45264) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gyI5I-0001P1-KN; Mon, 25 Feb 2019 10:22:26 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 388C43002DC2; Mon, 25 Feb 2019 15:22:22 +0000 (UTC) Received: from linux.fritz.box.com (ovpn-117-243.ams2.redhat.com [10.36.117.243]) by smtp.corp.redhat.com (Postfix) with ESMTP id 830795C22B; Mon, 25 Feb 2019 15:22:18 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Mon, 25 Feb 2019 16:20:27 +0100 Message-Id: <20190225152053.15976-46-kwolf@redhat.com> In-Reply-To: <20190225152053.15976-1-kwolf@redhat.com> References: <20190225152053.15976-1-kwolf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Mon, 25 Feb 2019 15:22:22 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 45/71] block: Use bdrv_dirname() for relative filenames X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Max Reitz bdrv_get_full_backing_filename_from_filename() breaks down when it comes to JSON filenames. Using bdrv_dirname() as the basis is better because since we have BDS, we can descend through the BDS tree to the protocol layer, which gives us a greater probability of finding a non-JSON name; also, bdrv_dirname() is more correct as it allows block drivers to override the generation of that directory name in a protocol-specific way. We still need to keep bdrv_get_full_backing_filename_from_filename(), though, because it has valid callers which need it during image creation when no BDS is available yet. This makes a test case in qemu-iotest 110, which was supposed to fail, work. That is actually good, but we need to change the reference output (and the comment in 110) accordingly. Signed-off-by: Max Reitz Reviewed-by: Alberto Garcia Message-id: 20190201192935.18394-20-mreitz@redhat.com Signed-off-by: Max Reitz --- block.c | 20 +++++++++++++------- tests/qemu-iotests/110 | 3 ++- tests/qemu-iotests/110.out | 2 +- 3 files changed, 16 insertions(+), 9 deletions(-) diff --git a/block.c b/block.c index 9f655c0fd6..185475ab00 100644 --- a/block.c +++ b/block.c @@ -337,16 +337,22 @@ char *bdrv_get_full_backing_filename_from_filename(co= nst char *backed, static char *bdrv_make_absolute_filename(BlockDriverState *relative_to, const char *filename, Error **err= p) { - char *bs_filename; + char *dir, *full_name; =20 - bdrv_refresh_filename(relative_to); + if (!filename || filename[0] =3D=3D '\0') { + return NULL; + } else if (path_has_protocol(filename) || path_is_absolute(filename)) { + return g_strdup(filename); + } =20 - bs_filename =3D relative_to->exact_filename[0] - ? relative_to->exact_filename - : relative_to->filename; + dir =3D bdrv_dirname(relative_to, errp); + if (!dir) { + return NULL; + } =20 - return bdrv_get_full_backing_filename_from_filename(bs_filename, - filename ?: "", er= rp); + full_name =3D g_strconcat(dir, filename, NULL); + g_free(dir); + return full_name; } =20 char *bdrv_get_full_backing_filename(BlockDriverState *bs, Error **errp) diff --git a/tests/qemu-iotests/110 b/tests/qemu-iotests/110 index b64b3b215a..3e9d72d302 100755 --- a/tests/qemu-iotests/110 +++ b/tests/qemu-iotests/110 @@ -60,7 +60,8 @@ echo '=3D=3D=3D Non-reconstructable filename =3D=3D=3D' echo =20 # Across blkdebug without a config file, you cannot reconstruct filenames,= so -# qemu is incapable of knowing the directory of the top image +# qemu is incapable of knowing the directory of the top image from the fil= ename +# alone. However, using bdrv_dirname(), it should still work. TEST_IMG=3D"json:{ 'driver': '$IMGFMT', 'file': { diff --git a/tests/qemu-iotests/110.out b/tests/qemu-iotests/110.out index b3584ff87f..5370bc1d26 100644 --- a/tests/qemu-iotests/110.out +++ b/tests/qemu-iotests/110.out @@ -14,7 +14,7 @@ backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGF= MT.base) image: json:{"driver": "IMGFMT", "file": {"set-state.0.event": "read_aio",= "image": {"driver": "file", "filename": "TEST_DIR/t.IMGFMT"}, "driver": "b= lkdebug", "set-state.0.new_state": 42}} file format: IMGFMT virtual size: 64M (67108864 bytes) -backing file: t.IMGFMT.base (cannot determine actual path) +backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGFMT.base) =20 =3D=3D=3D Backing name is always relative to the backed image =3D=3D=3D =20 --=20 2.20.1