Am 23.10.2014 um 20:00 hat Max Reitz geschrieben: > On 23.10.2014 19:42, Eric Blake wrote: > >On 10/23/2014 08:56 AM, Max Reitz wrote: > >>When using a relative backing file name, qemu needs to know the > >>directory of the top image file. For JSON filenames, such a directory > >>cannot be easily determined (e.g. how do you determine the directory of > >>a qcow2 BDS directly on top of a quorum BDS?). Therefore, do not allow > >>relative filenames for the backing file of BDSs only having a JSON > >>filename. > >> > >Are JSON names the only case where we want to do this, or should we > >widen it to all non-file protocol names? > > It'll probably work for HTTP, NFS of course and I can see it working > for NBD, too, if one is crazy enough to do that (and you're > mentioning glusterfs). In general, I think all filenames have some > normal unix-path-like sequence as their tail, so relative filenames > can work there (and maybe there are even people using it already for > all kinds of non-file protocols).
Perhaps make path_combine() a BlockDriver callback so that each block driver can implement relative paths the way they make most sense for it, or NULL to forbid them? We can still keep a common implementation for "normal" paths in block.c and reference that in raw-posix, curl, etc. Not sure how tricky it will become to integrate any of this relative file name handling nicely in a future, completely QDict-based bdrv_open()... Kevin
