Am 04.02.2016 um 17:35 hat Daniel P. Berrange geschrieben:
> On Thu, Feb 04, 2016 at 05:06:06PM +0100, Kevin Wolf wrote:
> > Am 04.02.2016 um 16:47 hat Daniel P. Berrange geschrieben:
> > > On Thu, Feb 04, 2016 at 04:42:06PM +0100, Kevin Wolf wrote:
> > > > Am 02.02.2016 um 13:57 hat Daniel P. Berrange geschrieben:
> > > > > @@ -1956,7 +2034,13 @@ static int img_convert(int argc, char **argv)
> > > > > goto out;
> > > > > }
> > > > >
> > > > > - out_blk = img_open("target", out_filename, out_fmt, flags, true,
> > > > > quiet);
> > > > > + /* XXX we should allow --image-opts to trigger use of
> > > > > + * img_open() here, but then we have trouble with
> > > > > + * the bdrv_create() call which takes different params.
> > > > > + * Not critical right now, so fix can wait...
> > > > > + */
> > > > > + out_blk = img_open_file("target", out_filename,
> > > > > + out_fmt, flags, true, quiet);
> > > >
> > > > So is the plan to add another option (like --target-image-opts) when
> > > > this call is converted?
> > >
> > > Well I was hoping --image-opts would affect both source and target,
> > > but i guess if we ship it only affecting source, we can't extend
> > > it to also affect target without back compat issues, so that might
> > > force adding a --target-image-opts
> >
> > Yes, that's exactly why I'm asking. We need to decide now whether this
> > would be an acceptable outcome or whether we shouldn't have --image-opts
> > in this command for now at all.
>
> I thinking having '--target-image-opts' wouldn't be the end of the world.
> I also get the feeling that solving the target problem may well require
> new cli args regardless, since there's multiple sets of options we care
> about - the image creation options are separate from the image runtime
> options in the block layer, and so given the image creation options theres
> no obvious way to extrapolate the subset which are also valid runtime
> options. Also AFAICT, we can't actually specify options at all for the
> layer below - it just assumes a plain file backend, so there's no way
> to pass options to express creation of qcow2-on-nbd for example, or
> formatting of luks-on-rbd, etc - only qcow2-on-file or luks-on-file.
Eventually I'd like to restructure bdrv_create() option handling similar
to bdrv_open() so that you can pass options explicitly to the protocol
layer, but for the time being, that's right, of course.
If having the options for the source is useful even without having them
for the target, I'm okay with having to add a new option later, if
nobody else objects to it.
Kevin
