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