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

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] VMX status report. Xen: #17630 & Xen0: #540 -- blocked
From: Kevin Wolf <kwolf@xxxxxxx>
Date: Thu, 15 May 2008 15:53:32 +0200
Cc: "Li, Haicheng" <haicheng.li@xxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 15 May 2008 06:58:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18476.13699.632075.410501@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <FC1D1B23302A22499C60C967336B2AE002C9AE25@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18474.49834.442492.313331@xxxxxxxxxxxxxxxxxxxxxxxx> <FC1D1B23302A22499C60C967336B2AE002C9B25F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36CA72200@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <482BFBBB.6030904@xxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36CA72230@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <482C0751.5000703@xxxxxxx> <18476.6533.343767.167852@xxxxxxxxxxxxxxxxxxxxxxxx> <482C2489.6050709@xxxxxxx> <18476.13699.632075.410501@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.12 (X11/20071114)
Ian Jackson schrieb:
Kevin Wolf writes ("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.

I think you've misunderstood, but I could be wrong.  To me it seems
that Qemu uses the terms `protocol' and `format' almost
interchangeably - I don't think they refer to different things.

I certainly don't want to exclude that I've misunderstood. But if it was meant to select the image format, the code looks overcomplicated to me.

And now that upstream qemu has a -drive parameter with a format option, we could get rid of this filename parsing in both ioemu and upstream qemu then. In Xen we don't use it anyway.

find_protocol, find_format and find_image_format all select from the
same set of bdrv_xxx drivers: find_format take a name and returns the
driver with that name; find_protocol takes a filename and looks for a
`:' in it, and if so it assumes that the part before the `:' is the
name and finds the driver with that name.  (Just for extra confusion
the two namespaces are different and some drivers don't have a name
that can be put in filenames, but some drivers have both names.)
find_image_format reads the start of the file and passes it to drivers
until one of them recognises it.

I think I understand quite well how it's processed in the code. ;-) And I also think that the code allows both of our understandings. If you wanted, I think you could add a "protocol" which in fact acts like a network protocol.

And the different namespaces still don't make too much sense to me if formats and protocols are really meant to be the same...

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.

These `protocols' aren't network protocols, they're disk image
formats.  The only ones which aren't a disk image format are vvfat and
(in ioemu) vbd.

vvfat is a crazy thing which you can't currently sanely layer anything
on top of (even though you might want to) and for which layering
a block driver underneath makes no sense.

I agree that vvfat isn't really a protocol as I understand them. It's only another block driver and it's using the protocol thing only because there was no format option qemu until recently. Maybe you're right and the "protocol" was only introduced as a hack to allow overriding the image format.

Kevin

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