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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list