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: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH 0/6] block: Add driver specific options
Date: Thu, 28 Feb 2013 10:35:01 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 28.02.2013 um 02:52 hat Eric Blake geschrieben:
> 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().

That's my plan at least, yes. When these options are used consistently,
in theory you should be able to say something like:

-drive file=/dev/fdset/1,format=qcow2,
    backing.file=/dev/fdset/2,backing.format=qcow2,backing.cache=writeback
    backing.backing.file=/dev/fdset/3,backing.format=raw

I'm not sure how pratical this really is for long backing file chains,
but it's a start. I think the real solution is setting up everything via
QMP, but we have been waiting for real solutions for too long already...

> > 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 :)

Great, thanks!

Kevin



reply via email to

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