Re: [Qemu-block] [Qemu-devel] [PATCH 7/7] qemu-img: allow specifying image as a set of options args

[Eric Blake]

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