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 17:42:00 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Dec 22, 2015 at 10:33:48AM -0700, Eric Blake wrote:
> On 12/22/2015 04:06 AM, Daniel P. Berrange wrote:
> > Currently qemu-img allows an image filename to be passed on the
> > command line, but does not have a way to set any options except
> > the format eg
> > 
> >    qemu-img info https://127.0.0.1/images/centos7.iso
> > 
> > This adds a --source arg (that is mutually exclusive with a
> > positional filename arg and -f arg) that accepts a full option
> > string, as well as the original syntax eg
> > 
> >    qemu-img info --source 
> > driver=http,url=https://127.0.0.1/images,sslverify=off
> 

[snip]

> 
> 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'.
> 
> 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.

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]