From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: VMX status report. Xen: #17630 & Xen0: #540 -- blocked Date: Thu, 15 May 2008 11:00:43 +0200 Message-ID: <482BFBBB.6030904@suse.de> References: <18474.49834.442492.313331@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Xu, Dongxiao" Cc: "Li, Haicheng" , xen-devel@lists.xensource.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org 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;