On 06/22/2010 03:10 AM, Kevin Wolf wrote:
Am 21.06.2010 17:34, schrieb Anthony Liguori:
On 06/21/2010 09:01 AM, Kevin Wolf wrote:
No, what I'm saying is that even in your model
-blockdev format=qcow2,file=image.qcow2,id=blk1
becomes qcow2 -> file automatically, whereas
-blockdev format=vvfat,file=/tmp/dir/,id=blk1
doesn't become vvfat -> file, but stays just vvfat.
I should say, that -blockdev format= vs. -blockdev transport= is
definitely at a place where I don't care that much.
The things that I think are most important are:
1) That we have structured options that map well to config file without
trickery to do nesting
2) That we don't automagically pass options through from the first layer
down to subsequent layers
Does this mean that you need to specify the protocol explicitly for any
non-trivial case? So if you want to use just default for everything you
can use
-blockdev id=foo,format=qcow2,file=foo.qcow2
Yes. I think we should explicitly support an option like file.
and it will be turned into something sensible automagically (namely
adding a file blockdev underneath and passing the file parameter to that
one), but if you want to change an option, you need to specify both?
-blockdev id=foo,format=qcow2,parent=foo_file
-blockdev id=foo_file,format=file,file=foo.qcow2,cache=off
What about read-only?
Good question. If a user specifies file, I think the (or generic block
layer) should have wide latitude to decide how to creating that backing
format which could include propagating options that it thinks are
reasonable (like readonly).
My concern is seeing something like:
-blockdev id=foo,format=qcow2,file=blah.img,funkyopt=value
or:
-blockdev id=foo,format=qcow2,protocol=[file=blah.img,funkyopt=value]
I think the later syntax is overwhelming. If the semantics of the
former syntax is "passthrough any options we don't understand at this
layer", I'm afraid it gets too confusing about which level actually
processed the option (and it certainly doesn't deal with propagation).
Regards,
Anthony Liguori
Is it something that must be specified for each
single node in the chain to actually get the right semantics?
Kevin
