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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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