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

Xu, Dongxiao schrieb:
> I just looked into this issue, and I was confused by the recursive function 
> call while opening a qcow file 
> (bdrv_open2->qcow_open->bdrv_file_open->bdrv_open2->...).
>     Remove the modification in block.c in C/S 17606 could work around this 
> issue, but it is not a good way.

I think the right solution is to remove bdrv_open altogether and force
the callers to provide the driver as parameter to bdrv_open2. For qcow
itself the following patch could be enough (compiles, but completely
untested).

But then, I don't even understand why find_protocol has been crippled -
isn't this one harmless and we should rather have removed the actual
guessing in find_image_format?

Kevin


diff -r 0beee5c839ea tools/ioemu/block.c
--- a/tools/ioemu/block.c       Tue May 13 12:17:08 2008
+++ b/tools/ioemu/block.c       Thu May 15 11:51:15 2008
@@ -329,7 +329,7 @@
     bs = bdrv_new("");
     if (!bs)
         return -ENOMEM;
-    ret = bdrv_open2(bs, filename, flags | BDRV_O_FILE, NULL);
+    ret = bdrv_open2(bs, filename, flags | BDRV_O_FILE, &bdrv_raw);
     if (ret < 0) {
         bdrv_delete(bs);
         return ret;

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