From nobody Wed Apr 16 07:35:56 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1499447479286950.7253231887468; Fri, 7 Jul 2017 10:11:19 -0700 (PDT) Received: from localhost ([::1]:57694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTWmj-0006OQ-MT for importer@patchew.org; Fri, 07 Jul 2017 13:11:17 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTWko-0004X8-Dz for qemu-devel@nongnu.org; Fri, 07 Jul 2017 13:09:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTWkm-0007Wm-My for qemu-devel@nongnu.org; Fri, 07 Jul 2017 13:09:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45740) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dTWkg-0007Ro-H1; Fri, 07 Jul 2017 13:09:10 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E10F5BECD; Fri, 7 Jul 2017 17:09:09 +0000 (UTC) Received: from noname.redhat.com (ovpn-117-34.ams2.redhat.com [10.36.117.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6697762924; Fri, 7 Jul 2017 17:09:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4E10F5BECD Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kwolf@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4E10F5BECD From: Kevin Wolf To: qemu-block@nongnu.org Date: Fri, 7 Jul 2017 19:07:16 +0200 Message-Id: <1499447335-6125-2-git-send-email-kwolf@redhat.com> In-Reply-To: <1499447335-6125-1-git-send-email-kwolf@redhat.com> References: <1499447335-6125-1-git-send-email-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 07 Jul 2017 17:09:09 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 001/100] qemu-io: Don't die on second open 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, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Eric Blake Most callback commands in qemu-io return 0 to keep the interpreter loop running, or 1 to quit immediately. However, open_f() just passed through the return value of openfile(), which has different semantics of returning 0 if a file was opened, or 1 on any failure. As a result of mixing the return semantics, we are forcing the qemu-io interpreter to exit early on any failures, which is rather annoying when some of the failures are obviously trying to give the user a hint of how to proceed (if we didn't then kill qemu-io out from under the user's feet): $ qemu-io qemu-io> open foo qemu-io> open foo file open already, try 'help close' $ echo $? 0 In general, we WANT openfile() to report failures, since it is the function used in the form 'qemu-io -c "$something" no_such_file' for performing one or more -c options on a single file, and it is not worth attempting $something if the file itself cannot be opened. So the solution is to fix open_f() to always return 0 (when we are in interactive mode, even failure to open should not end the session), and save the return value of openfile() for command line use in main(). Note, however, that we do have some qemu-iotests that do 'qemu-io -c "open file" -c "$something"'; such tests will now proceed to attempt $something whether or not the open succeeded, the same way as if the two commands had been attempted in interactive mode. As such, the expected output for those tests has to be modified. But it also means that it is now possible to use -c close and have a single qemu-io command line operate on more than one file even without using interactive mode. Although the '-c open' action is a subtle change in behavior, remember that qemu-io is for debugging purposes, so as long as it serves the needs of qemu-iotests while still being reasonable for interactive use, it should not be a problem that we are changing tests to the new behavior. This has been awkward since at least as far back as commit e3aff4f, in 2009. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng Reviewed-by: John Snow Signed-off-by: Kevin Wolf --- qemu-io.c | 7 ++++--- tests/qemu-iotests/060.out | 1 + tests/qemu-iotests/114.out | 5 +++-- tests/qemu-iotests/153.out | 6 ++++++ 4 files changed, 14 insertions(+), 5 deletions(-) diff --git a/qemu-io.c b/qemu-io.c index 8e38b28..8074656 100644 --- a/qemu-io.c +++ b/qemu-io.c @@ -230,13 +230,14 @@ static int open_f(BlockBackend *blk, int argc, char *= *argv) qemu_opts_reset(&empty_opts); =20 if (optind =3D=3D argc - 1) { - return openfile(argv[optind], flags, writethrough, force_share, op= ts); + openfile(argv[optind], flags, writethrough, force_share, opts); } else if (optind =3D=3D argc) { - return openfile(NULL, flags, writethrough, force_share, opts); + openfile(NULL, flags, writethrough, force_share, opts); } else { QDECREF(opts); - return qemuio_command_usage(&open_cmd); + qemuio_command_usage(&open_cmd); } + return 0; } =20 static int quit_f(BlockBackend *blk, int argc, char **argv) diff --git a/tests/qemu-iotests/060.out b/tests/qemu-iotests/060.out index 3bc1461..5ca3af4 100644 --- a/tests/qemu-iotests/060.out +++ b/tests/qemu-iotests/060.out @@ -21,6 +21,7 @@ Format specific information: refcount bits: 16 corrupt: true can't open device TEST_DIR/t.IMGFMT: IMGFMT: Image is corrupt; cannot be o= pened read/write +no file open, try 'help open' read 512/512 bytes at offset 0 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) =20 diff --git a/tests/qemu-iotests/114.out b/tests/qemu-iotests/114.out index b6d10e4..1a47a52 100644 --- a/tests/qemu-iotests/114.out +++ b/tests/qemu-iotests/114.out @@ -1,6 +1,6 @@ QA output created by 114 -Formatting 'TEST_DIR/t.IMGFMT.base', fmt=3DIMGFMT size=3D67108864=20 -Formatting 'TEST_DIR/t.IMGFMT', fmt=3DIMGFMT size=3D67108864 backing_file= =3DTEST_DIR/t.IMGFMT.base=20 +Formatting 'TEST_DIR/t.IMGFMT.base', fmt=3DIMGFMT size=3D67108864 +Formatting 'TEST_DIR/t.IMGFMT', fmt=3DIMGFMT size=3D67108864 backing_file= =3DTEST_DIR/t.IMGFMT.base image: TEST_DIR/t.IMGFMT file format: IMGFMT virtual size: 64M (67108864 bytes) @@ -8,6 +8,7 @@ cluster_size: 65536 backing file: TEST_DIR/t.IMGFMT.base backing file format: foo can't open device TEST_DIR/t.qcow2: Could not open backing file: Unknown d= river 'foo' +no file open, try 'help open' read 4096/4096 bytes at offset 0 4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) *** done diff --git a/tests/qemu-iotests/153.out b/tests/qemu-iotests/153.out index 5ba0b63..5b917b1 100644 --- a/tests/qemu-iotests/153.out +++ b/tests/qemu-iotests/153.out @@ -33,10 +33,12 @@ Is another process using the image? _qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: Failed to get "write" lock Is another process using the image? +no file open, try 'help open' =20 _qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock Is another process using the image? +no file open, try 'help open' =20 _qemu_img_wrapper info TEST_DIR/t.qcow2 qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" = lock @@ -99,6 +101,7 @@ _qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2 =20 _qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: force-share=3Don can only be used with= read-only images +no file open, try 'help open' =20 _qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512 =20 @@ -166,6 +169,7 @@ _qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2 _qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: Failed to get "write" lock Is another process using the image? +no file open, try 'help open' =20 _qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512 =20 @@ -214,6 +218,7 @@ _qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2 =20 _qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: force-share=3Don can only be used with= read-only images +no file open, try 'help open' =20 _qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512 =20 @@ -313,6 +318,7 @@ _qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2 =20 _qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512 can't open device TEST_DIR/t.qcow2: force-share=3Don can only be used with= read-only images +no file open, try 'help open' =20 _qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512 =20 --=20 1.8.3.1