Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling

[Kevin Wolf]

Am 17.03.2011 19:28, schrieb Anthony Liguori:
> On 03/17/2011 10:22 AM, Markus Armbruster wrote:
>>> I wanted to share these plans early hoping to get some feedback and
>>> also to maybe interest some folks in helping out.
>> There's also QEMUOptionParameter, thankfully limited to block code.  Any
>> plans to cover that as well?
> 
> QCFG will replace this because the BlockdevConfig structure can be 
> passed throughout the block layer to enable block format specific 
> options to be implemented.
> 
> QEMUOptionParameter is just used for bdrv_create today right?

I think so.

I created it for bdrv_create, and when Gerd needed something similar not
much later, it turned out that we wanted to add some more features. So
Gerd turned it into QemuOpts, but left the old interface instead of
replacing it in the existing users. Everything newer than that should be
using QemuOpts.

> Do we 
> want create options to be different than run time options or would a 
> superset of the two be appropriate?

Run time options would be things like cache mode etc.? I don't think we
have an image format that can store these, so it doesn't make a lot of
sense to provide them in bdrv_create.

For opening an image, I think we have three levels of options, in this
order: Defaults that are set by the block driver, options that are read
from an image, options specified on the command line. It seems to make
sense to allow this for any option.

Kevin