Re: [Qemu-devel] [RFC] Using BlockdevRef in the block layer

[Max Reitz <mreitz@redhat.com>]

On 06.12.2013 11:45, Kevin Wolf wrote:
> Am 05.12.2013 um 19:35 hat Max Reitz geschrieben:
>> On 05.12.2013 18:41, Max Reitz wrote:
>>> […]
>>>
>>> Second, if specifying a reference to an existing device should
>>> really be supported, bdrv_open() should ideally not call
>>> bdrv_file_open() anymore, but a function bdrv_find_ref() instead
>>> which resolves a BlockdevRef structure (for simplicity, it appears
>>> to be easier to use a QDict equivalent to a BlockdevRef instead of
>>> the latter itself (since that results in many effectively
>>> redundant conversions to and from those representations)).
>>> However, bdrv_file_open() supports parsing protocol filenames,
>>> which bdrv_find_ref() would not. As a result, it is probably best
>>> to call bdrv_find_ref() from bdrv_file_open() instead and leave
>>> bdrv_open() generally the way it is right now – yes, this is a
>>> question. ;-) (“Do you agree?”)
>> I noticed only just now that the current design does not seem to
>> allow nesting of files (i.e., driver=blkdebug-qmp,
>> file.driver=qcow2, file.file.driver=file). Perhaps I do have to call
>> bdrv_find_ref() in bdrv_open() and only resort to bdrv_file_open()
>> if a filename that must be parsed was given...?
> This is supposed to work. If it doesn't work today, it is a bug or
> missing implementation rather than a design decision.

The top level bdrv_open() will call bdrv_file_open() with {driver=qcow2, 
file.driver=file}. This in turn calls bdrv_open_common() with file=NULL 
which will fail, since qcow2 expects a file to be present 
(drv->bdrv_file_open == NULL && file == NULL). At least, that is what 
happened for me when I tried this.

Max