Re: [PATCH] ALSA: emu10k1: fix error codes

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Sat, Apr 22, 2023 at 09:46:24AM +0200, Takashi Iwai wrote:
>On Fri, 21 Apr 2023 19:26:23 +0200, Oswald Buddenhagen wrote:
>> One might argue that this potentially breaks user space, but a) this 
>> is
>> just one driver among many, so it seems unlikely that someone would
>> expect (only) the broken codes and b) it seems unlikely that someone
>> would check these syscalls for particular errors at all, rather than
>> just logging them (this might be debatable for the voice allocator
>> calls).
>
>I find this is too risky for really little win.
>
yes, the gain is relatively low. it merely means applications displaying 
somewhat less confusing error messages.

>The error code is
>returned to user space in quite many cases; e.g. the voice allocator
>is called from PCM hw_params, too, and that's most of user-space
>programs do actually check.  It could be a surprise if it's changed
>without much reason, may trigger unexpected behavior changes.
>
of course. hypothetically.
but these aren't error codes around which specific error recovery would 
exist.
codes that actually _have_ error recovery built around them tend to be 
already correct, because people actually tried using them and noticed 
mistakes in time.

>Of course, if the error code must be corrected, we can fix it.
>But I don't see it in this patch description.
>
i can provide a rationale for each of the changes, even though i think 
that the patch context speaks for itself - the theme is always "return 
an error code whose description better reflects the situation being 
reported".
but none of that would change the fact that it would break code that was 
specifically designed to rely on this driver's bogus behavior. i just 
don't think such code exists, because that wouldn't make any sense.
so i don't know what your criteria for "must be corrected" are.

regards