qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 7/7] qemu-img: allow specifying ima


From: Daniel P. Berrange
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 7/7] qemu-img: allow specifying image as a set of options args
Date: Tue, 22 Dec 2015 18:07:55 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Dec 22, 2015 at 10:50:19AM -0700, Eric Blake wrote:
> 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).

A third option would be to keep using positional arguments, but
add a '--source-opts' *boolean* flag to indicate how to interpret
the positional arguments.  ie without --source-opts we use the
historic syntax, but with --source-opts, we assume the full QemuOpts
syntax.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]