[PATCH] tools/hotplug/Linux/blktap: remove optional tapdisk: prefix

[PATCH] tools/hotplug/Linux/blktap: remove optional tapdisk: prefix

[Jan Beulich]

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

Perhaps this should even be further generalized (e.g. to remove any
"[!/]*:" pattern prefixes) to be more forward compatible?

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- a/tools/hotplug/Linux/blktap	2010-02-16 18:06:25.000000000 +0100
+++ b/tools/hotplug/Linux/blktap	2010-04-16 11:46:29.000000000 +0200
@@ -59,6 +59,7 @@
 if [ -n "$t" ]
 then
     p=$(xenstore_read "$XENBUS_PATH/params")
+    p=${p#tapdisk:}
     # if we have a ':', chew from head including :
     if echo $p | grep -q \:
     then




[-- Attachment #2: xen-tools-blktap-script.patch --]
[-- Type: text/plain, Size: 528 bytes --]

Perhaps this should even be further generalized (e.g. to remove any
"[!/]*:" pattern prefixes) to be more forward compatible?

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- a/tools/hotplug/Linux/blktap	2010-02-16 18:06:25.000000000 +0100
+++ b/tools/hotplug/Linux/blktap	2010-04-16 11:46:29.000000000 +0200
@@ -59,6 +59,7 @@
 if [ -n "$t" ]
 then
     p=$(xenstore_read "$XENBUS_PATH/params")
+    p=${p#tapdisk:}
     # if we have a ':', chew from head including :
     if echo $p | grep -q \:
     then

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] tools/hotplug/Linux/blktap: remove optional tapdisk: prefix

[Jim Fehlig]

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

Jan Beulich wrote:
> Perhaps this should even be further generalized (e.g. to remove any
> "[!/]*:" pattern prefixes) to be more forward compatible?
>   

Right.  Need to handle the 'ioemu' subtype as well.  How about just
stripping of everything before the leading '/'?  E.g. like the attached
patch?

Regards,
Jim


[-- Attachment #2: blktap-script.patch --]
[-- Type: text/x-patch, Size: 530 bytes --]

diff -r c02cc832cb2d tools/hotplug/Linux/blktap
--- a/tools/hotplug/Linux/blktap	Tue Apr 13 18:19:33 2010 +0100
+++ b/tools/hotplug/Linux/blktap	Fri Apr 16 14:48:00 2010 -0600
@@ -59,10 +59,10 @@
 if [ -n "$t" ]
 then
     p=$(xenstore_read "$XENBUS_PATH/params")
-    # if we have a ':', chew from head including :
+    # if we have a ':', remove everything up to leading '/'
     if echo $p | grep -q \:
     then
-        p=${p#*:}
+        p="/${p#*/}"
     fi
 fi
 # some versions of readlink cannot be passed a regular file

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] tools/hotplug/Linux/blktap: remove optional tapdisk: prefix

[Jan Beulich]

>>> Jim Fehlig <jfehlig@novell.com> 16.04.10 22:51 >>>
>Jan Beulich wrote:
>> Perhaps this should even be further generalized (e.g. to remove any
>> "[!/]*:" pattern prefixes) to be more forward compatible?
>>   
>
>Right.  Need to handle the 'ioemu' subtype as well.  How about just
>stripping of everything before the leading '/'?  E.g. like the attached
>patch?

Wouldn't that become wrong when remote locations are acceptable
here (not sure if they aren't already), i.e. server:/path/file? If that
is not expected to ever have a meaning and if relative paths aren't
permitted here, then yes, that would of course be the best solution.

Jan

Re: [PATCH] tools/hotplug/Linux/blktap: remove optional tapdisk: prefix

[Jim Fehlig]

Jan Beulich wrote:
>>>> Jim Fehlig <jfehlig@novell.com> 16.04.10 22:51 >>>
>>>>         
>> Jan Beulich wrote:
>>     
>>> Perhaps this should even be further generalized (e.g. to remove any
>>> "[!/]*:" pattern prefixes) to be more forward compatible?
>>>   
>>>       
>> Right.  Need to handle the 'ioemu' subtype as well.  How about just
>> stripping of everything before the leading '/'?  E.g. like the attached
>> patch?
>>     
>
> Wouldn't that become wrong when remote locations are acceptable
> here (not sure if they aren't already), i.e. server:/path/file? 

IMO, remote locations should be handled by another tap driver optimized
for the remote file protocol, similar to the nbd, curl, etc. block
backends in qemu.

> If that
> is not expected to ever have a meaning and if relative paths aren't
> permitted here, then yes, that would of course be the best solution.
>   

The tools currently don't cope with relative paths in disk specification.

Jim