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=file,file=/path/to/file' as a filename would try to look in a >> relative directory 'driver=file,file=', whereas your proposal of always >> using the new '--source' option would make it obvious that we are >> expecting to parse a QemuOpts string rather than defaulting to a literal >> 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 =), 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 option
>> as mutually exclusive with positional args, vs. just adding a new
>> interpretation of the existing mandatory positional arguments?
>
> 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.
>
> 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 :)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
