All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Krempa <pkrempa@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	Libvirt <libvir-list@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Klaus Jensen <its@irrelevant.dk>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 11/11] Deprecate stable non-JSON -device and -object
Date: Mon, 27 Sep 2021 13:27:34 +0200	[thread overview]
Message-ID: <YVGqptZGZ6PhqixP@redhat.com> (raw)
In-Reply-To: <CAFEAcA-Paf0+BvdFrT=B_jfzCNzGB6w4-7hjBeXWt0sJJYJs-Q@mail.gmail.com>

Am 27.09.2021 um 11:00 hat Peter Maydell geschrieben:
> On Fri, 24 Sept 2021 at 10:14, Kevin Wolf <kwolf@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@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:

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.

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.

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".

Yes, we could in theory do a more limited deprecation. The planned
change from my side is just going from QemuOpts to the keyval parser,
which doesn't change anything in the vast majority of cases.

But we have the separation in the monitor between QMP and HMP for a good
reason: Requirements for a good machine interface are different from a
good human interface. The same is true for the command line.

So it seems to make a lot of sense to me to have both a machine
interface (JSON based) and a human interface (non-JSON) on the command
line, too, and take the same liberties for evolving the human interface
as we already do in HMP - which means that it's technically an unstable
interface where compatibility doesn't prevent improvements, but not that
it looks completely different in every QEMU version.

Kevin



  reply	other threads:[~2021-09-27 11:30 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24  9:04 [PATCH 00/11] qdev: Add JSON -device and fix QMP device_add Kevin Wolf
2021-09-24  9:04 ` [PATCH 01/11] qom: Reduce use of error_propagate() Kevin Wolf
2021-09-24 13:23   ` Vladimir Sementsov-Ogievskiy
2021-09-24 14:04   ` Markus Armbruster
2021-09-24 18:14   ` Eric Blake
2021-09-24  9:04 ` [PATCH 02/11] iotests/245: Fix type for iothread property Kevin Wolf
2021-09-24 13:33   ` Vladimir Sementsov-Ogievskiy
2021-09-24  9:04 ` [PATCH 03/11] iotests/051: Fix typo Kevin Wolf
2021-09-24 13:35   ` Vladimir Sementsov-Ogievskiy
2021-09-24  9:04 ` [PATCH 04/11] qdev: Avoid using string visitor for properties Kevin Wolf
2021-09-24 18:40   ` Eric Blake
2021-09-24  9:04 ` [PATCH 05/11] qdev: Make DeviceState.id independent of QemuOpts Kevin Wolf
2021-09-24 14:02   ` Vladimir Sementsov-Ogievskiy
2021-09-24 15:10     ` Kevin Wolf
2021-09-24 15:14       ` Vladimir Sementsov-Ogievskiy
2021-09-24  9:04 ` [PATCH 06/11] qdev: Add Error parameter to qdev_set_id() Kevin Wolf
2021-09-24 14:09   ` Vladimir Sementsov-Ogievskiy
2021-09-27 10:33     ` Damien Hedde
2021-10-05 11:09       ` Kevin Wolf
2021-09-24  9:04 ` [PATCH 07/11] qemu-option: Allow deleting opts during qemu_opts_foreach() Kevin Wolf
2021-09-24 14:14   ` Vladimir Sementsov-Ogievskiy
2021-09-24  9:04 ` [PATCH 08/11] qdev: Base object creation on QDict rather than QemuOpts Kevin Wolf
2021-09-24 18:53   ` Eric Blake
2021-09-24  9:04 ` [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add Kevin Wolf
2021-09-24 18:56   ` Eric Blake
2021-09-27 11:06   ` Damien Hedde
2021-09-27 11:39     ` Kevin Wolf
2021-10-05 14:37       ` Kevin Wolf
2021-10-05 15:52         ` Damien Hedde
2021-10-05 17:33           ` Kevin Wolf
2021-10-06  8:21             ` Juan Quintela
2021-10-06  9:20               ` Laurent Vivier
2021-10-06 10:53                 ` Kevin Wolf
2021-10-06 11:09                   ` Laurent Vivier
2021-10-01 14:42   ` Peter Krempa
2021-10-04 12:18     ` Damien Hedde
2021-10-04 14:22       ` Kevin Wolf
2021-09-24  9:04 ` [PATCH 10/11] vl: Enable JSON syntax for -device Kevin Wolf
2021-09-24 19:00   ` Eric Blake
2021-09-24  9:04 ` [PATCH 11/11] Deprecate stable non-JSON -device and -object Kevin Wolf
2021-09-24 19:02   ` Eric Blake
2021-09-27  8:15   ` Paolo Bonzini
2021-09-27  8:21     ` Daniel P. Berrangé
2021-09-27 10:17       ` Kevin Wolf
2021-09-27 10:37         ` Daniel P. Berrangé
2021-09-27  9:00   ` Peter Maydell
2021-09-27 11:27     ` Kevin Wolf [this message]
2021-09-27 12:52       ` Peter Maydell
2021-09-27 16:10         ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YVGqptZGZ6PhqixP@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=its@irrelevant.dk \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.