From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwxtr-0003QU-Aw for qemu-devel@nongnu.org; Wed, 10 Jul 2013 13:09:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uwxtn-0005nO-FL for qemu-devel@nongnu.org; Wed, 10 Jul 2013 13:09:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwxtn-0005nD-84 for qemu-devel@nongnu.org; Wed, 10 Jul 2013 13:09:51 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6AH9oPd012981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Jul 2013 13:09:50 -0400 Message-ID: <51DD955C.1040506@redhat.com> Date: Wed, 10 Jul 2013 11:09:48 -0600 From: Eric Blake MIME-Version: 1.0 References: <1373464273-7934-1-git-send-email-kwolf@redhat.com> In-Reply-To: <1373464273-7934-1-git-send-email-kwolf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2QOPFJIDGLREUPVSTSRGK" Subject: Re: [Qemu-devel] [PATCH] block: Don't parse protocol from file.filename List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QOPFJIDGLREUPVSTSRGK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/10/2013 07:51 AM, Kevin Wolf wrote: > One of the major reasons for doing something new for -blockdev and > blockdev-add was that the old block layer code parses filenames instead= > of just taking them literally. So we should really leave it untouched > when it's passing using the new interfaces (like -drive > file.filename=3D...). >=20 > This allows opening relative file names that contain a colon. Will a protocol prefix ever contain a '/'? Would it be desirable to state that relative file names containing a colon should be specified as './file:name', with the '/' serving as the escape that means relative file rather than attempting to use protocol './file:', even when using legacy options? >=20 > Signed-off-by: Kevin Wolf > --- > block.c | 17 ++++++++++++----- > block/sheepdog.c | 2 +- > include/block/block.h | 3 ++- > qemu-img.c | 4 ++-- > tests/qemu-iotests/051 | 12 ++++++++++++ > tests/qemu-iotests/051.out | 14 ++++++++++++++ > 6 files changed, 43 insertions(+), 9 deletions(-) >=20 > @@ -813,7 +817,10 @@ int bdrv_file_open(BlockDriverState **pbs, const c= har *filename, > drv =3D bdrv_find_whitelisted_format(drvname, !(flags & BDRV_O= _RDWR)); > qdict_del(options, "driver"); > } else if (filename) { > - drv =3D bdrv_find_protocol(filename); > + drv =3D bdrv_find_protocol(filename, allow_protocol_prefix); > + if (!drv) { > + qerror_report(ERROR_CLASS_GENERIC_ERROR, "Unknown protocol= "); > + } If you want to allow './' as a forceful non-protocol escape even in legacy parsing, then this code may need tweaking. Otherwise, I think the code looks fine. Reviewed-by: Eric Blake > +++ b/tests/qemu-iotests/051 > @@ -149,6 +149,18 @@ echo > run_qemu -drive file=3D$TEST_IMG,file.driver=3Dfile > run_qemu -drive file=3D$TEST_IMG,file.driver=3Dqcow2 > =20 > +echo > +echo =3D=3D=3D Parsing protocol from file name =3D=3D=3D > +echo > + > +# Protocol strings are supposed to be parsed from traditional option s= trings, > +# but not when using driver-specific options. We can distinguish them = by the > +# error message for non-existing files. Is it also worth testing that we successfully open a file name with a colon from driver-specific options, or is that harder to do portably (since windows doesn't allow : in file names except for the drive prefix)= ? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2QOPFJIDGLREUPVSTSRGK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR3ZVcAAoJEKeha0olJ0NqsRAIAI8tHXKdPKfTSYymkclVVQJx gX4NEawu3erQPQWqEyhL7wSNaUJBWZPGU+Nz4vAN0tCnth88YNReNJ9Ub87Pbps5 4fbPlVa/55HiJqTL0vt0qs0Nr4+0gBAsBafuoVUXpoQt72DCyhVDAPkGWYbIuE7Y 9OPnhXg+mDjuUKfxXsb4enGoKHLGwochIFvMcjo8WgBxdCE899XVZcu1vqx0I1Di xIpKycJ8d7BY0dvyPYxRoGXaM550bvMdFIOwllA/2gGZ74YOB6086mPJRXnLWGug TlEcISbWRer9/xJvi+mLTPGQZYTSh5k3xKEjcyNcc+PyJ5TRRFC7gD/sDBQpcM4= =pO5I -----END PGP SIGNATURE----- ------enig2QOPFJIDGLREUPVSTSRGK--