qemu-block
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial
Date: Thu, 12 Jul 2018 08:38:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 10.07.2018 um 16:22 hat Cornelia Huck geschrieben:
>> 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");
>> 
>> 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?
>
> I think the function should just take a message:
>
>     /* Works like error_report(), except for the WARNING/ERROR prefix
>      * and exit(1) if -no-deprecated-options is set */
>     void deprecation_report(const char *fmt, ...);

I like it.  The contract could use a bit of polish, but that's detail.

> We don't necessarily deprecate only options, but we might also deprecate
> monitor commands, specific options values (while keeping other values of
> the same option) etc.

Exactly.



reply via email to

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