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

[Kevin Wolf <kwolf@xxxxxxx>]

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