Re: [PATCH v3] qapi: give available enum values as error hint

[Markus Armbruster]

Marc-André Lureau <marcandre.lureau@redhat.com> writes:

> Hi
>
> On Wed, Mar 8, 2023 at 5:55 PM Markus Armbruster <armbru@redhat.com> wrote:
>
>> marcandre.lureau@redhat.com writes:
>>
>> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
>> >
>> > This allows for a more pleasant user experience.
>> >
>> > Before:
>> > $ ./qemu-system-x86_64 -display egl-headless,gl=
>> > qemu-system-x86_64: -display egl-headless,gl=: Parameter 'gl' does not 
>> > accept value ''
>> >
>> > After:
>> > $ ./qemu-system-x86_64 -display egl-headless,gl=
>> > qemu-system-x86_64: -display egl-headless,gl=: Parameter 'gl' does not 
>> > accept value ''
>> > Acceptable values are 'off', 'on', 'core', 'es'
>> >
>> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> Nice improvement here.
>>
>> Slightly ugly:
>>
>>     $ qemu-system-x86_64 -nic bad
>>     upstream-qemu: -nic bad: Parameter 'type' does not accept value 'bad'
>>     Acceptable values are 'none', 'nic', 'user', 'tap', 'l2tpv3', 'socket', 
>> 'stream', 'dgram', 'vde', 'bridge', 'hubport', 'netmap', 'vhost-user', 
>> 'vhost-vdpa'
>>
>> Outright annoying:
>>
>> $ upstream-qemu -object bad
>> upstream-qemu: -object bad: Parameter 'qom-type' does not accept value 'bad'
>> Acceptable values are 'authz-list', 'authz-listfile', 'authz-pam', 
>> 'authz-simple', 'can-bus', 'can-host-socketcan', 'colo-compare', 
>> 'cryptodev-backend', 'cryptodev-backend-builtin', 'cryptodev-backend-lkcf', 
>> 'dbus-vmstate', 'filter-buffer', 'filter-dump', 'filter-mirror', 
>> 'filter-redirector', 'filter-replay', 'filter-rewriter', 'input-barrier', 
>> 'input-linux', 'iothread', 'main-loop', 'memory-backend-epc', 
>> 'memory-backend-file', 'memory-backend-memfd', 'memory-backend-ram', 
>> 'pef-guest', 'pr-manager-helper', 'qtest', 'rng-builtin', 'rng-egd', 
>> 'rng-random', 'secret', 'secret_keyring', 'sev-guest', 'thread-context', 
>> 's390-pv-guest', 'throttle-group', 'tls-creds-anon', 'tls-creds-psk', 
>> 'tls-creds-x509', 'tls-cipher-suites', 'x-remote-object', 
>> 'x-vfio-user-server'
>>
>> Note we already let users ask for this information with -object help or
>> -object qom-type=help.  Sadly, we can't hint at that here, because it's
>> implemented much further up the call chain, and other call chains don't.
>>
>> If HMP command sendkey didn't bypass the input visitor, the 26 screen
>> lines of hint for QKeyCode would likely scroll the error message off the
>> screen.
>>
>> Should we suppress this hint when it's too long to be useful?
>
> I don't have strong opinions.. perhaps stop after first 5 with "..." ?

A hint like "Use CMD to show the possible values" would be better, but
it's not feasible now.

Instead of cutting off after five, we cut off when the hint goes beyond
a length limit.  A bit more involved.  Up to you.

Enumerations with more than five members:

      6 BlkdebugIOType
      6 EvtchnPortType
      6 GrabToggleKeys
      6 HmatLBDataType
      6 SevState
      7 AudioFormat
      7 QCryptoHashAlgorithm
      7 SchemaMetaType
      7 WatchdogAction
      8 JSONType
      9 DisplayType
      9 InputButton
      9 JobType
      9 VncPrimaryAuth
      9 VncVencryptSubAuth
     11 JobStatus
     11 ShutdownCause
     12 AudiodevDriver
     12 QCryptoCipherAlgorithm
     12 TransactionActionKind
     14 MigrationStatus
     16 RunState
     17 NetClientDriver
     21 MigrationCapability
     22 ChardevBackendKind
     31 SysEmuTarget
     44 ObjectType
     47 BlockdevDriver
     48 BlkdebugEvent
    150 QKeyCode

Not all of them are can be visited from CLI or HMP (which is how the
hint gets used).

> (Ideally, we would have shell completion scripts that would be able to help
> us, but hey that's another level! :)

True :)