Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, May 10, 2019 at 02:17:11PM -0300, Eduardo Habkost wrote:
> On Fri, May 10, 2019 at 11:29:53AM +0200, Markus Armbruster wrote:
> [...]
> > I'm afraid our command line is awkward both for machines and for humans,
> > albeit for different reasons.
> > 
> > For humans doing simple things, the command line is okay.  But beyond
> > that, it gets forbiddingly unwieldy[2].
> > 
> > Machines are fine with that kind of unwieldy, but would prefer something
> > with more structure, both on input (talking to QEMU) and even more so on
> > output (QEMU talking back).
> > 
> > Ideally, we'd support machines do their work in (structured) QMP,
> > resorting to the command line only to set up a QMP monitor.  We're not
> > anywhere close to this.
> > 
> > As long as management applications use the command line in not-trivial
> > ways, they have to deal with configuration errors reported via stderr.
> 
> That's only true if we want to.
> 
> Command line is an interface usable by machines.  Not the ideal,
> but it works.
> 
> Messages on stderr are not an interface for machines.  We must
> provide something better, and I don't think "wait until we
> convert everything to QMP" is a reasonable answer.

If QEMU successfully starts then libvirt essentially ignores stderr
just letting it go to the logfile.

If we see any deprecated features used during startup the natural
thing would be to queue up a list of warnings, and then once the
client (libvirt) connects to QMP emit them as events.

QEMU still ought to emit them on stderr anyway so they do end up
in the logs regardless of whether anyone actually procsses the
deprecation QMP events.

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 :|