qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Matthew Booth <mbooth@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/3] curl: Fix parsing of readahead option from filename
Date: Thu, 01 May 2014 06:04:50 -0600	[thread overview]
Message-ID: <53623862.1050603@redhat.com> (raw)
In-Reply-To: <53620C41.3040506@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On 05/01/2014 02:56 AM, Matthew Booth wrote:
> On 30/04/14 16:16, Kevin Wolf wrote:
>> Am 30.04.2014 um 16:20 hat Matthew Booth geschrieben:
>>> curl_parse_filename wasn't removing the option string from the url,
>>> resulting in a 404.
>>>


> 
> Alternatively I could completely change the syntax. However, the only
> 'safe' syntax I can think of would involve ugly custom escaping, which
> would probably catch out more people than unsafe option parsing. I'm
> open to suggestions.

The name is a URI, so it should already be possible to use URI escaping
(percent-hex-hex) for any character that must be interpreted as part of
the filename rather than as a bogus query.  Therefore, you should be
strict and require that the user passes in a valid URI with all options
known and with the filename spelled correctly using URI escapes, rather
than loose and parsing what would otherwise be garbage as a possible
weird filename.

> 
> On a related note, do you know if it's possible to specify a backing
> file with separated options? i.e.:
> 
> qemu-img create -f qcow2 -o
> backingfile.url='http://example.com/path',backingfile.readahead='64k'
> /tmp/foo.qcow2

It should be possible; in fact, if the backing file is supported in
BlockdevOptions for the QMP blockdev-add command it already is.  If it
is not supported in BlockdevOptions, then we need structured options
added to make it possible.  But you can use any of the backing stores
that are already structured as your example.

> 
> I suspect that qcow2 only stores a string, so probably not, but I
> thought I'd ask.

There's a proposal for a new json: protocol, which allows storing ANY
arbitrary BlockdevOptions as a flat string in the qcow2 metadata (within
the limits of the header format which forces you to 1024 bytes or less).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2014-05-01 12:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1398867658-2069-1-git-send-email-mbooth@redhat.com>
     [not found] ` <1398867658-2069-2-git-send-email-mbooth@redhat.com>
     [not found]   ` <20140430151638.GE4380@noname.redhat.com>
2014-05-01  8:56     ` [Qemu-devel] [PATCH 1/3] curl: Fix parsing of readahead option from filename Matthew Booth
2014-05-01 12:04       ` Eric Blake [this message]
2014-05-05  9:27       ` Kevin Wolf
     [not found] ` <1398867658-2069-3-git-send-email-mbooth@redhat.com>
     [not found]   ` <20140430152017.GF4380@noname.redhat.com>
2014-05-01  8:59     ` [Qemu-devel] [PATCH 2/3] curl: Add sslverify option Matthew Booth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53623862.1050603@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mbooth@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).