[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 00/15] block: Overriding the backing file with -

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 00/15] block: Overriding the backing file with -drive
Date: Thu, 18 Apr 2013 15:34:38 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 18.04.2013 um 13:42 hat Stefan Hajnoczi geschrieben:
> On Fri, Apr 12, 2013 at 10:47:53PM +0200, Kevin Wolf wrote:
> > This is the next part of the driver-specific options. Looks like we're 
> > getting
> > closer to pass file descriptors for the whole backing file chain. In fact, I
> > hope we're now only lacking QMP support before we can actually use it. :-)
> > 
> > This series adds support for the backing.* options namespace, and allows to 
> > use
> > the file.filename option to configure the filename string for non-top-level
> > BlockDriverStates. In the end you can use things like:
> > 
> >     -drive file=test.qcow2,backing.file.filename=/dev/fdset/1,
> >     backing.backing.file.driver=nbd,backing.backing.file.host=localhost
> Nice series.
> > On another note, I'm still not sure whether I should leave all of this work
> > enabled for 1.5, or if we wouldn't be better off with disabling it for the
> > release so that we have some additional months before we commit to the
> > interface. Any opinions?
> I suggest we leave this series and the io_flush series I sent recently
> out of QEMU 1.5.  Once they are reviewed, let's merge them into
> block-next.  When 1.6 opens they'll be the first things to get merged.

There have already two other series gone in that deal with driver
specific options. If we decide to not enable this in 1.5 (which I agree
is probably better), then I think I'd be inclined to merge this series
and put another patch in that re-enables the old strict option checking
in drive_init() and therefore effectively disables all of these changes.

> Unless there's an urgent need to get this into 1.5, I don't see the big
> win - QMP changes are still missing anyway.  Let's not rush it.
> Also, I guess documentation changes are missing to really make this
> feature ready for end-users :).

Yes, there are definitely enough missing pieces. Though I must admit
that the part that really worries me is committing to an external API
before we are sure that the syntax can stays as it is when all pieces
are there. I wouldn't have much problems with exposing it if we were
sure that it's the right thing and it's just incomplete yet.


reply via email to

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