[libvirt] [PATCH 4/4] Support for probing qed image metadata

[Eric Blake]

On 11/23/2010 06:26 AM, Stefan Hajnoczi wrote:
>> More worrying, I don't see anything in QED that requires the filename to
>> occur within the first 10K bytes.  Do we need to add another enum value
>> to libvirt's backing store callback routine, to be used when the header
>> requests data that lies beyond buf_size but is still feasibly valid, for
>> the case where QED designates a backing store location that is beyond
>> 10k but still before the start of the first cluster, rather than the
>> current approach of just treating it as BACKING_STORE_INVALID?
> 
> QED doesn't explicitly restrict
> backing_filename_offset/backing_filename_size to just the header
> cluster(s).  I think it makes sense to say backing_filename_offset +
> backing_filename_size <= header_size * cluster_size and will add it to
> the QED spec.

Thanks.  Do you also want to require that backing_filename_offset >
sizeof(backing_filename_size)+offsetof(header,backing_filename_size)?
That is, it doesn't make sense for the backing filename to overlap with
existing header elements.

> 
> But that doesn't guarantee backing_filename_offset < 10 KB.  The space
> after struct QEDHeader is explicitly unstructured so extensions can
> put arbitrary data there in a backwards compatible way.

I agree that QED should not have to arbitrarily restrict things because
of libvirt.  Rather, libvirt should be patched to be able to find a
backing filename that lies beyond 10K but still within the header clusters.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20101123/4f80479c/attachment-0001.sig>