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: Eric Blake
Subject: Re: [Qemu-devel] [RFC PATCH 0/6] block: Add driver specific options
Date: Wed, 27 Feb 2013 18:52:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3

On 02/27/2013 10:25 AM, 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.

So, if I understand the implications correctly, this lays the framework
so that a future patch series can let me specify a qcow2-specific -drive
option that says to use an existing fd in place of opening the backing
file directly from the information in the qcow2 header?  If so, I'm
stoked - we might actually be able to reach the point where we can have
libvirt pass all fds and block qemu from using open().

> 
> 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.

I'm sure the libvirt folks can manage to work with whatever syntax we
end up with, but I'll try to give this a UI design review anyways.  The
internals I might leave to others to review, and I can understand if
changes in the internals end up affecting the command-line UI before all
is said and done (that is, I'm not writing any libvirt code to target
this just yet :)

> 
> 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.
> 
> 
> Kevin Wolf (6):
>   block: Add options QDict to .bdrv_open()
>   block: Add options QDict to bdrv_open() prototype
>   Add qdict_clone_shallow()
>   block: Add options QDict to bdrv_open_common()
>   block: Support driver specific options in drive_init()
>   qcow2: Allow lazy refcounts to be enabled on the command line
> 
>  block.c                   | 73 
> +++++++++++++++++++++++++++++++++++++++--------
>  block/blkverify.c         |  2 +-
>  block/bochs.c             |  2 +-
>  block/cloop.c             |  2 +-
>  block/cow.c               |  2 +-
>  block/dmg.c               |  2 +-
>  block/parallels.c         |  2 +-
>  block/qcow.c              |  2 +-
>  block/qcow2-cluster.c     |  2 +-
>  block/qcow2.c             | 26 +++++++++++++++--
>  block/qcow2.h             |  1 +
>  block/qed.c               |  4 +--
>  block/raw.c               |  2 +-
>  block/vdi.c               |  2 +-
>  block/vmdk.c              |  4 +--
>  block/vpc.c               |  2 +-
>  block/vvfat.c             |  2 +-
>  blockdev.c                | 63 +++++++++++++++++++++++++++++++++++-----
>  hw/xen_disk.c             |  2 +-
>  include/block/block.h     |  4 +--
>  include/block/block_int.h |  3 +-
>  include/qapi/qmp/qdict.h  |  2 ++
>  qemu-img.c                |  6 ++--
>  qemu-io.c                 |  2 +-
>  qemu-nbd.c                |  2 +-
>  qobject/qdict.c           | 22 ++++++++++++++
>  26 files changed, 191 insertions(+), 47 deletions(-)
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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