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

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.

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.

> 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.

vbd is a mistake; it should be minios's block_raw.

>   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...)

The reason they're using bdrv functions is so that they can go through
the bdrv_raw driver for backing file and image file accesses; this is
necessary to preserve the properties of the block IO abstraction
through the various layers.

Ian.

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