qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC PATCH 0/6] block: Add driver specific options
Date: Thu, 28 Feb 2013 11:23:57 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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