7:52 a.m.
On Mon, 27 Sept 2021 at 12:27, Kevin Wolf <kwolf(a)redhat.com> wrote:
Am 27.09.2021 um 11:00 hat Peter Maydell geschrieben:
> On Fri, 24 Sept 2021 at 10:14, Kevin Wolf <kwolf(a)redhat.com> wrote:
> >
> > We want to switch both from QemuOpts to the keyval parser in the future,
> > which results in some incompatibilities, mainly around list handling.
> > Mark the non-JSON version of both as unstable syntax so that management
> > tools switch to JSON and we can later make the change without breaking
> > things.
> >
> > Signed-off-by: Kevin Wolf <kwolf(a)redhat.com>
>
> > +Stable non-JSON ``-device`` and ``-object`` syntax (since 6.2)
> >
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> > +
> > +If you rely on a stable interface for ``-device`` and ``-object`` that
doesn't
> > +change incompatibly between QEMU versions (e.g. because you are using the
QEMU
> > +command line as a machine interface in scripts rather than interactively),
use
> > +JSON syntax for these options instead.
> > +
> > +There is no intention to remove support for non-JSON syntax entirely, but
> > +future versions may change the way to spell some options.
>
> As it stands, this is basically saying "pretty much anybody
> using the command line, your stuff may break in future, instead
> use some other interface you've never heard of, which doesn't
> appear to be documented in the manual and which none of the
> documentation's examples use".
The documentation is a valid criticism. We need to document the JSON
interfaces properly (which will really mostly be a pointer to the
existing QMP documentation at least for -object, but it's important to
tell people where to look for the details).
> Is there some more limited deprecation we can do rather than "the
> entire commandline for almost all users" ?
I don't think "almost all" users is true.
I see three groups of users
...all of whom "rely on a stable interface for -device and -object",
and only two of whom it's reasonable to say "use the JSON version" to.
1. Using a management tool that is probably using libvirt. This is
likely the vast majority of users. They won't notice a difference
because libvirt abstracts it away. libvirt developers are actively
asking us for JSON (and QAPI) based interfaces because using the same
representation to describe configurations in QMP and on the CLI makes
their life easier.
Yes, absolutely we should be recommending that libvirt and
other management interfaces use the JSON.
2. People starting QEMU on the command line manually. This is
essentially the same situation as HMP: If something changes, you get
an error message, you look up the new syntax, done. Small
inconvenience, but that's it. This includes simple scripts that just
start QEMU and are only used to store a long command line somewhere.
It's a small inconvenience that we seem to be imposing on our
users on a pretty frequent basis. Moreover, each one of these
really needs to be its own deprecation, so that users actually
can have some advance notice if they need it and look up the
new syntax. We shouldn't hide them all under this umbrella
"we might break anything at any time" entry, which I think
will pretty much encourage breaking compatibility more often
because you don't have to think about "oh, we should deprecate
this and maybe print warnings about use of deprecated syntax
and then drop it later", you can just break things and point
to this "we said -device wasn't going to be stable" entry.
As a concrete example, the commit message for this patch vaguely
mentions some issues "around list handling", which gives me no
idea at all about what syntax is going to break in future or
whether it is likely to affect scripts I've written.
3. People writing more complex scripts or applications that invoke
QEMU
manually instead of using libvirt. They may actually be hurt by such
changes. They should probably be using a proper machine interface,
i.e. JSON mode, so the deprecation notice is for them to change
their code. This is probably a small minority and not "almost all
users".
Yeah, this group is kind of similar to group 1 (well, at one
end it shades into group 1 and at the other into group 2).
More generally, I think I'd rather see the deprecation of
the old approach appear after some period when the JSON
command line version has been available to users and adopted
by major consumers like libvirt, not as a patch in the same
series which is introducing the JSON syntax in the first plaec.
-- PMM