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
