qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: block: format vs. protocol, and how they stack


From: Anthony Liguori
Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack
Date: Tue, 22 Jun 2010 08:07:30 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

On 06/22/2010 07:57 AM, Kevin Wolf wrote:
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?

Yes.  I think once you do an explicit option, you have to be very careful.

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.

I understand the concern but I think one of the big problems with -drive and bdrv_open today is they are far too magical. We shouldn't make the same mistake again.

We ought to keep in my the 80/20 rule. In this case, I'm fairly certain that it's closer to 99% of users are only doing 1% of what is actually possible and generally that's going to either be -hda foo.img or -blockdev file=foo.img,option=value.

Regards,

Anthony Liguori

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]