On Wed, Feb 07, 2024 at 08:58:09PM +0300, Michael Tokarev wrote:
> - create more or less consistent set of options between different
> subcommands
> - provide long options which can be used without figuring out which
> -T/-t, -f|-F|-O etc to use for which of the two images given
> - have qemu-img --help provide just a list of subcommands
> - have qemu-img COMMAND --help to describe just this subcommand
> - get rid of qemu-img-opts.hx, instead finish documentation in
> qemu-img.rst based on the actual options implemented in
> qemu-img.c.
Yes, yes, yes, yes & more yes :-)
I cry every time I have to read the qemu-img --help output,
and I'm not much of a fan of the man page either to be fair,
as I don't like the global list of options at the top which
is divorced from which commands actually use them.
These days I see many programs with subcommands switching to
a separate man page per sub-command. Still, I'm not asking
you todo that too, its just an idea for the gallery.
> I started converting subcommands one by one, providing long options
> and --help output. And immediately faced some questions which needs
> wider discussion.
>
> o We have --image-opts and --target-image-opts. Do we really need both?
> In my view, --image-opts should be sort of global, turning *all*
> filenames on this command line into complete image specifications,
> there's no need to have separate image-opts and --target-image-opts.
> Don't know what to do wrt compatibility though. It shouldn't be made
> this way from the beginning. As a possible solution, introduce a new
> option and deprecate current set.
This is basically a crutch for incomplete conversion of the block
layer APIs, which meant we had a situation where we wanted to use
image opts syntax for the source, but were unable todo so for
the target:
commit 305b4c60f200ee8e6267ac75f3f5b5d09fda1079
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: Mon May 15 17:47:11 2017 +0100
qemu-img: introduce --target-image-opts for 'convert' command
The '--image-opts' flag indicates whether the source filename
includes options. The target filename has to remain in the
plain filename format though, since it needs to be passed to
bdrv_create(). When using --skip-create though, it would be
possible to use image-opts syntax. This adds --target-image-opts
to indicate that the target filename includes options. Currently
this mandates use of the --skip-create flag too.
we do have internal support for creating block devices using
the full QAPI schema, via BlockdevCreateOptions.
I'm not sure if bdrv_create can be made to create using the
image-opts syntax. If it can, there is still the additional
problem that after creation it then needs to re-open the
file, and the image-opts for open is defined by BlockdevOptions
not BlockdevCreateOptions. So we would need a way to convert
from the latter to the former.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
