qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 03/17] iotests: ask qemu for suppor


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 03/17] iotests: ask qemu for supported formats
Date: Thu, 07 Jun 2018 08:57:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Thomas Huth <address@hidden> writes:

> On 05.06.2018 00:40, Eric Blake wrote:
>> On 06/04/2018 05:34 AM, Thomas Huth wrote:
>>> On 04.06.2018 09:18, Markus Armbruster wrote:
>>>> Roman Kagan <address@hidden> writes:
>>>>
>>>>> Add helper functions to query the block drivers actually supported by
>>>>> QEMU using "-drive format=?".  This allows to skip certain tests that
>>>>> require drivers not built in or whitelisted in QEMU.
>>>>>
>> 
>>>>> +    supported_formats=$($QEMU_PROG $QEMU_OPTIONS -drive format=\?
>>>>> 2>&1 | \
>>>>
>>>> Use of '?' to get help is deprecated.  Please use 'format=help', and
>>>> update your commit message accordingly.
>>>
>>> Is it? Where did we document that?
>> 
>> Hmm, we haven't documented it yet, but it's been that way since commit
>> c8057f95, in Aug 2012, when we added 'help' as the preferred synonym,
>> and have tried to avoid mention of '?' in new documentation (as it
>> requires additional shell quoting).  I'm guessing we'll probably see a
>> patch from you to start an official deprecation window?
>
> I'm using '?' regularly on my own, so don't expect a patch from
> my side here ;-)
> Anyway, we still use the question mark in our documentation, e.g.:
>
> options
>
>     is a comma separated list of format specific options in a name=value 
> format.
>     Use -o ? for an overview of the options supported by the used format or 
> see
>     the format descriptions below for details.
>
> or:
>
> -b, --blacklist=list
>
>     Comma-separated list of RPCs to disable (no spaces, ‘?’ to list available 
> RPCs)

These are bugs, and we need to fix them.

> So calling it deprecated sounds wrong to me.

Our intent to deprecate it was pretty clear in commit c8057f95:

    /**
     * is_help_option:
     * @s: string to test
     *
     * Check whether @s is one of the standard strings which indicate
     * that the user is asking for a list of the valid values for a
     * command option like -cpu or -M. The current accepted strings
-->  * are 'help' and '?'. '?' is deprecated (it is a shell wildcard
     * which makes it annoying to use in a reliable way) but provided
     * for backwards compatibility.
     *
     * Returns: true if @s is a request for a list.
     */
    static inline bool is_help_option(const char *s)

Predates today's more formal deprecation policy.  Simpler times.

There's no real need to kill off '?', unless it gets in the way of
steering people towards 'help'.  We should steer them toward 'help',
because '?' is a trap for insufficiently sophisticated users of
shell[*].

Every use of '?' in our source tree works against that goal, and thus
works towards a removal of '?'.



[*] In the wider sense, approximately 99.99% of shell users are
insufficiently sophisticated, including myself.  In the narrower sense
of being prone to fall into the '?' trap, the fraction is lower, but
still significant.



reply via email to

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