From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBR52-0002Sp-8q for qemu-devel@nongnu.org; Tue, 22 Dec 2015 12:50:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBR50-000890-Rx for qemu-devel@nongnu.org; Tue, 22 Dec 2015 12:50:36 -0500 References: <1450782389-17326-1-git-send-email-berrange@redhat.com> <1450782389-17326-8-git-send-email-berrange@redhat.com> <5679897C.7060003@redhat.com> <20151222174159.GM10082@redhat.com> From: Eric Blake Message-ID: <56798D5B.4040800@redhat.com> Date: Tue, 22 Dec 2015 10:50:19 -0700 MIME-Version: 1.0 In-Reply-To: <20151222174159.GM10082@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3rL24Nw9EXqUdsRRAvFDEd4aXChH9U76T" Subject: Re: [Qemu-devel] [PATCH 7/7] qemu-img: allow specifying image as a set of options args List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , =?UTF-8?Q?Andreas_F=c3=a4rber?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3rL24Nw9EXqUdsRRAvFDEd4aXChH9U76T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/22/2015 10:42 AM, Daniel P. Berrange wrote: >> Overall, I'm left wondering whether requiring '--source FOO' vs. >> positional 'FOO', and manually enforcing mutual exclusion between the >> two, is necessary, or if we could stick with positional. But I guess >> the main argument is backwards-compatibility: previously, using >> 'driver=3Dfile,file=3D/path/to/file' as a filename would try to look i= n a >> relative directory 'driver=3Dfile,file=3D', whereas your proposal of a= lways >> using the new '--source' option would make it obvious that we are >> expecting to parse a QemuOpts string rather than defaulting to a liter= al >> file name. >> >> On the other hand, the existing positional parameters have allowed >> 'file:file:with_weird_name' to explicitly specify that we want to use >> './file:with_weird_name' as a relative file in the current directory >> (that is, the first 'file:' prefix is sufficient to avoid any >> back-compat issues with any other possible change in interpretation to= a >> prefix), so on that grounds, I'd argue that adding --source is not >> necessary, and we can just require users to write >> 'file:$string_that_might_now_be_QemuOpts' anywhere they used to use >> '$string_that_might_now_be_QemuOpts'. I guess there's also the issue of literal commas. Right now, we have: $ echo hi > a,b $ qemu-img info a,b image: a,b file format: raw virtual size: 512 (512 bytes) disk size: 4.0K $ qemu-img info file:a,b image: a,b file format: raw virtual size: 512 (512 bytes) disk size: 4.0K If we magically change things to interpret the positionals as QemuOpts strings, we'd have a change that: $ qemu-img info a,b $ qemu-img info file:a,b would error out ('a' and 'file:a' are not a known options, and we are expecting =3D), but at the same time: $ qemu-img info a,,b $ qemu-img info file:a,,b would start working (because the use of ',,' is the QemuOpts way to escape a literal ',' that is not separating options packed into the single argument). >> >> Maybe other block developers have an opinion to offer on whether the >> last three patches in this series should be adding a new --source opti= on >> as mutually exclusive with positional args, vs. just adding a new >> interpretation of the existing mandatory positional arguments? >=20 > Yep, back compatibility to avoid breaking any existing possible > filenames was my main motivation for adding '--source'. I agree > it would be nice if we decided that the risk was acceptable > based on what you say above, and thus avoid --source, and just > extend existing positional args. >=20 > If block maintainers OK that approach, I'd happily rewrite the > last 3 patches in this series in that manner. It may be mid-January before the decision is made, but we've got time before 2.6 soft freeze. I can wait :) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --3rL24Nw9EXqUdsRRAvFDEd4aXChH9U76T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWeY1bAAoJEKeha0olJ0NqsYsH/2GL6wVZcn7mB6lWLlKep+ev K5T1YWG2lXN6DpoDfo19qchWy8Jdr981JpKoiItd1fvKVsXJcKKElGOKMb7qnnV5 YyOTj6rQwH1AU94U+8sVS0m9JarCWerjEwU1RVvPlx93tnH0v7FW4qlWoEMGDm9E OW+iR3AdOWU4/tYQHbSPK2rj0db74R19Fiu3InyVugPyUiwmSS/BJhJF2lmibfrR aC4p4k4/rWF70SGmQegu4IfU/CbVu5wxHOkErGnxJIe/t0BKX7x6AgkKQuTaRlqc soA+JR05vIlDLvZw6t6bhpmHoUTGTPmWaPN3QhUeeHmzSpmw+yDlP9aqTaxiNN8= =MOvg -----END PGP SIGNATURE----- --3rL24Nw9EXqUdsRRAvFDEd4aXChH9U76T--