[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive

From: Peter Krempa
Subject: Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial
Date: Tue, 10 Jul 2018 16:39:31 +0200
User-agent: Mutt/1.10.0 (2018-05-17)

On Tue, Jul 10, 2018 at 16:22:08 +0200, Cornelia Huck wrote:
> On Tue, 10 Jul 2018 07:59:15 +0200
> Markus Armbruster <address@hidden> wrote:
> > In addition to actively pulling libvirt developers into review of
> > deprecation patches, we should pursue the idea to optionally let QEMU
> > fail on use of deprecated features, then have libvirt run its test suite
> > that way.
> What about the following:
> qemu_deprecated_option("old_option", "modern_option");

I think this is too simplified. You can deprecate only a certain value
for an option or even just a combination of values and options. The
check will need to be programatic and error reporting probably can't be
reasonably machine readable anyways.

> Which would then print (in normal operation)
> "WARNING: 'old_option' is deprecated and will be removed; use 'modern_option' 
> instead"
> to the monitor (or to stderr? to both?).
> If you start QEMU with a -no-deprecated-options switch, it would print
> "ERROR: 'old_option' is deprecated and will be removed; use 'modern_option' 
> instead"
> and do an exit(1).
> Would that be workable?

For delivering the warnings via monitor you'll need a store that will
collect all the warnings and prepare them for delivery. You've got
basically two options:

1) monitor command to poll for deprecated options
2) event with deprecated options

Both require storing them since libvirt connects to the monitor only
after the command line is processed.

Warnings printed to stderr are nearly useless because until something
breaks nobody bothers to read the log files.

To make any reasonable use of -no-deprecated-options we'd also need
something that simulates qemu startup (no resources are touched in fact)
so that we can run it against the testsuite. Otherwise the use will be
limited to developers using it with the configuration they are
currently testing.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]