From: Paolo Bonzini <pbonzini@redhat.com>
To: bharata@linux.vnet.ibm.com
Cc: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Anand Avati <aavati@redhat.com>,
Vijay Bellur <vbellur@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
Harsh Bora <harsh@linux.vnet.ibm.com>,
Amar Tumballi <amarts@redhat.com>,
qemu-devel@nongnu.org, "Richard W.M. Jones" <rjones@redhat.com>,
Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
Daniel Veillard <veillard@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v9 4/4] block: Support GlusterFS as a QEMU block backend.
Date: Thu, 27 Sep 2012 09:19:34 +0200 [thread overview]
Message-ID: <5063FE06.3070304@redhat.com> (raw)
In-Reply-To: <20120927064132.GB18285@in.ibm.com>
Il 27/09/2012 08:41, Bharata B Rao ha scritto:
>>> As you note, I don't need 2nd strtok strictly since the rest of the string
>>> is available in saveptr. But I thought using saveptr is not ideal or preferred.
>>> I wanted to use the most appropriate/safe delimiter to extract the image string
>>> in the 2nd strtok and decided to use '?'.
>>
>> I don't think it is defined what saveptr points to.
>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf2/strtok_r.htm
>> says "the strtok_r subroutine also updates the Pointer parameter with
>> the starting address of the token following the first occurrence of the
>> Separators parameter". I read this as:
>>
>> *saveptr = token + strlen(token) + 1;
>>
>> which is consistent with this strtok example from the C standard:
>>
>> #include <string.h>
>> static char str[] = "?a???b,";
>> char *t;
>>
>> t = strtok(str, "?"); // t points to the token "a"
>> t = strtok(str, ","); // t points to the token "??b"
>>
>> Have you tested this code with multiple consecutive slashes?
>
> Yes, both 2-strtok and strtok+saveptr approach work correctly (= as per
> my expectation!) with multiple consecutive slashes. I do understand that
> 2-strtok approach will not work when we have %3F in the path component of
> the URI.
>
> For URIs like gluster://server/volname/path/to/image, both the approaches
> extract image as "path/to/image".
>
> For URIs like gluster://server/volname//path/to/image, both the approaches
> extract image as "/path/to/image".
>
> For gluster://server/volname////path/to/image, the image is extracted as
> "//path/to/image".
Should there be three /'s here? I assume it's just a typo.
I'm concerned that there is no documentation of what saveptr actually
points to. In many cases the strtok specification doesn't leave much
free room, but in the case you're testing here:
>>> /* image */
>>> if (!*saveptr) {
>>> return -EINVAL;
>>> }
strtok_r may just as well leave saveptr = NULL for example.
>>> gconf->image = g_strdup(saveptr);
>>>
>>
>> I would avoid strtok_r completely:
>>
>> char *p = path + strcpsn(path, "/");
>> if (*p == '\0') {
>> return -EINVAL;
>> }
>> gconf->volname = g_strndup(path, p - path);
>>
>> p += strspn(p, "/");
>> if (*p == '\0') {
>> return -EINVAL;
>> }
>> gconf->image = g_strdup(p);
>
> This isn't working because for a URI like
> gluster://server/volname/path/to/image, uri_parse() will give
> "/volname/path/to/image" in uri->path. I would have expected to see
> uri->path as "volname/path/to/image" (without 1st slash).
Ok, that's easy enough to fix with an extra strspn,
char *p = path + strpsn(path, "/");
p += strcspn(p, "/");
> Note that gluster is currently able to resolve image paths that don't
> have a preceding slash (like dir/a.img). But I guess we should support
> specifying complete image paths too (like /dir/a.img)
How would the URIs look like?
Paolo
next prev parent reply other threads:[~2012-09-27 7:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 9:10 [Qemu-devel] [PATCH v9 0/4] GlusterFS support in QEMU - v9 Bharata B Rao
2012-09-24 9:10 ` [Qemu-devel] [PATCH v9 1/4] aio: Fix qemu_aio_wait() to maintain correct walking_handlers count Bharata B Rao
2012-09-24 9:12 ` [Qemu-devel] [PATCH v9 2/4] qemu: URI parsing library Bharata B Rao
2012-09-24 10:27 ` Richard W.M. Jones
2012-09-24 11:11 ` Paolo Bonzini
2012-09-27 9:03 ` Avi Kivity
2012-09-27 9:07 ` Paolo Bonzini
2012-10-02 4:59 ` Daniel Veillard
2012-10-02 6:16 ` Paolo Bonzini
2012-09-24 9:12 ` [Qemu-devel] [PATCH v9 3/4] configure: Add a config option for GlusterFS as block backend Bharata B Rao
2012-09-24 9:13 ` [Qemu-devel] [PATCH v9 4/4] block: Support GlusterFS as a QEMU " Bharata B Rao
2012-09-24 9:26 ` Paolo Bonzini
2012-09-24 9:44 ` Bharata B Rao
2012-09-26 10:00 ` Kevin Wolf
2012-09-26 10:08 ` Paolo Bonzini
2012-09-26 16:11 ` Bharata B Rao
2012-09-26 16:38 ` Paolo Bonzini
2012-09-27 6:41 ` Bharata B Rao
2012-09-27 7:19 ` Paolo Bonzini [this message]
2012-09-27 8:28 ` Bharata B Rao
2012-09-27 8:31 ` Paolo Bonzini
2012-10-03 15:50 ` [Qemu-devel] O_DIRECT on glusterfs (was Re: [PATCH v9 4/4] block: Support GlusterFS as a QEMU block backend) Paolo Bonzini
2012-10-03 17:58 ` Anand Avati
2012-10-03 18:17 ` Paolo Bonzini
2012-10-03 18:17 ` Anand Avati
2012-10-03 18:27 ` Paolo Bonzini
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=5063FE06.3070304@redhat.com \
--to=pbonzini@redhat.com \
--cc=aavati@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=amarts@redhat.com \
--cc=avi@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=harsh@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@gmail.com \
--cc=vbellur@redhat.com \
--cc=veillard@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).