Re: [Qemu-devel] [RFC PATCH 0/6] block: Add driver specific options

[Kevin Wolf]

Am 28.02.2013 um 11:23 hat Stefan Hajnoczi geschrieben:
> On Wed, Feb 27, 2013 at 06:25:49PM +0100, Kevin Wolf wrote:
> > Instead of constantly keeping complaining that we need this big -blockdev
> > things, let's start attacking individual parts of the project. Here is the
> > first part, allowing block drivers to provide additional -drive options.
> > 
> > Any options that isn't processed by the block layer is passed to the driver
> > which can use them. If it doesn't, you get an error message like today. At 
> > the
> > end of this series you can specify:
> > 
> >   -drive file=test.qcow2,lazy_refcounts=on
> > 
> > This is still quite rough and more of a quick hack, but I'd like to get some
> > feedback on the general approach and for example if at least the user 
> > interface
> > is acceptable. I thought -drive already mixes so many things, messing a bit
> > more with it can't make things much worse, but you may disagree.
> 
> Quick comment before diving into the patches:
> 
> The consequence of this syntax is that option name collisions may become
> a problem in the future.  The chance is low but when you string together
> a protocol with a format there is already a chance that both
> BlockDrivers want an option.  This is the multiple inheritance problem
> in object oriented language: did the user mean to set both options?
> Just one and which?  etc

Yeah, I wasn't planning to allow that. Options are for the format. If
you want to address the protocol, we can use a similar syntax as
suggested below for backing files, like 'file.discard=ignore'.

> However, when we get -blockdev this is no longer an issue.  And in the
> meantime this patch series seems to add a useful feature.

More importantly, I believe it's the only way to get closer to the
real -blockdev. We have to do things incrementally.

> > Before merging this, I'll look into using QemuOpts a bit more (the manual
> > parsing of the option in qcow2 definitely has to go away) and possibly allow
> > specifying options for backing files or the protocol as well with a syntax 
> > like
> > "backing.lazy_refcounts=on". If all options starts using this, maybe even
> > something like "backing.cache=writeback" could be made to work.
> 
> Introducing a new <foo>.<option> namespace pushes the necessity for
> -blockdev farther into the future.

Yes, that's the dangerous thing about it. :-) But we can't wait another
five years to get the functionality...

Kevin