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

[Takashi Iwai <tiwai@suse.de>]

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