On 03.03.2014 15:02, Jun Li wrote:
Such as how to visit glusterfs:
file=gluster://1.2.3.4/testvol/a.img
file=gluster+tcp://1.2.3.4/testvol/a.img
file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
file=gluster+rdma://1.2.3.4:24007/testvol/a.img
----
So if only the path contain "://", the path maybe contain a protocol. So use
strstr() to replace func strcspn().
Signed-off-by: Jun Li <junm...@gmail.com>
---
block.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Currently, a protocol prefix is only defined to end with a colon, not
with ":/" or "://". There are already protocol block drivers which do
not require a slash after the colon such as blkdebug or blkverify and I
deem it rather impossible to redefine their filename format now (in
order to make them use ":/").
Thus, I do not think it will be this easy. I am in fact not even sure
whether it is possible at all (automagically doing the right thing) –
currently, a colon simpy is the separator between protocol and filename.
Just using the "file" protocol per default for the whole filename if
there is no protocol with a name equal to the pre-colon part is probably
not what we want, since the user may actually be referring to some
protocol that the qemu version he/she is using does not support (yet),
in which case creating a file with a name including the pre-colon part
(the protocol name) is most probably not the right thing to do.
Henceforth, in my opinion, we either have to ask the user in that case
or we introduce some new option which disables protocol prefixes. I
think the easiest way to do the latter is to introduce a
bdrv_parse_filename() function for the "file" protocol drivers which
remove a "file:" prefix if given. Then, the user could just specify
"file:foo:bar.img" to reference a file named "foo:bar.img".
Currently, the behavior is that such a prefix will be interpreted
correctly (the "file" protocol is selected) but it is not removed. Thus,
"file:foo:bar.img" will actually reference a file named
"file:foo:bar.img". One could argue that removing the prefix therefore
breaks current behavior, but I sincerely hope nobody has relied on that
behavior so far.
Max