WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked

Ian Jackson schrieb:
> Could those of you having this problem please try the attached patch ?
> I have tested this one much more thoroughly :-/.

It works for me, I don't like it though. Maybe I don't understand correctly what the intent of the whole protocol stuff was. But if I do, I think you're destroying this with your patch. This is not necessarily bad as we don't use it anyway. But then it would be much cleaner to remove the functionality altogether.

To be a bit more concrete, I think the following change is wrong (even if there is no user anyway):

-    /* no need to test disk image formats for vvfat */
-    if (drv == &bdrv_vvfat)
+    /* no need to test disk image format if the filename told us */
+    if (drv != NULL)
         return drv;

find_protocol doesn't tell you the image format of a file, it tells you a protocol through which you should obtain the image. And the image you get could be a qcow image then. I think the reason why they are using bdrv functions for all file accesses is that e.g. the qcow driver could use the protocol driver then (if there was any protocol driver...)

Currently xend won't let you specify a filename with a protocol specifier anyway, so removing the whole thing is certainly an option.

Kevin

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