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).
Right, if we get to use a default value, we can propagate things that
the generic block layer knows. However, as soon as someone specifies a
protocol explicitly, he'll need to add readonly=on to each -blockdev in
the chain?
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).
The former involves definitely too much magic for assigning the options
to the right blockdev. The latter would be more comprehensible, but
isn't really nice either.
On the other hand, funkyopt might be something as common as cache, and
I'd hate to require specifying the protocol explicitly in a second
-blockdev referenced by another ID when you just want to change the
cache option.