Re: [Qemu-devel] [PATCH 1/2] block: JSON filenames and relative backing files

[Kevin Wolf <kwolf@redhat.com>]

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