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
