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 However, when we get -blockdev this is no longer an issue. And in the meantime this patch series seems to add a useful feature. > 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. I'm reminded that GlusterFS has a working module graph which can be configured (plus CLI tools for common use cases). It's not an impossible problem, we're just not very good at or keen on defining interfaces :). Stefan
