On Sat, 22 Apr 2023 14:04:36 +0200, Oswald Buddenhagen wrote: > > 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. Yes, but remember that they adapt how the existing code behaves; so even if EBUSY might appears like a better fit, a different error code may bring unexpected outcome. User space programs can do every crazy thing, so never underestimate a subtle change if it's visible -- that's what I've learned from the long development history. Especially true, if the stuff is a very old one like this. That said, I wouldn't mind changing if it's about a new driver code. But this isn't such a case. > > 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. So my take is rather to skip this. thanks, Takashi
