Re: [PATCH] firewire: Replace ENOSYS with appropriate error codes

[Nirbhay Sharma <nirbhay.lkd@gmail.com>]

On 11/17/25 5:01 PM, Takashi Sakamoto wrote:
> Hi,
>   
> Yes. The newly-written code should not use ENOSYS for cadual use, indeed.
> 
>   
> There is a rest to discuss when changing existing code in respect to
> this topic, since it brings loss of backward-compatibility to userspace
> software. In this reason, I've left them as is.
> 
> If there are any strong and specific reasons to correct them, let us
> change them. Do you have such reasons? For example, Linux kernel
> developer have shared the consensus and decision to ostracize such codes?
> 
> 
> Thanks
> 
> Takashi Sakamoto

Hi Takashi,

Thank you for your detailed review and explanation.

You are absolutely right about the backward compatibility concern. I 
realize now that changing error codes in existing code paths could break 
userspace applications that might be checking for specific error values.

My patch was motivated by the checkpatch.pl warning and the general 
kernel policy that ENOSYS should only mean "invalid syscall number." 
BUt, I didn't fully consider the userspace ABI implications of changing 
error codes in code that's already been released.

I do not have a strong technical reason beyond code correctness to 
justify breaking backward compatibility in this case. Since these 
interfaces are already in use and userspace software may depend on the 
current behavior, the risk of breaking existing applications outweighs 
the benefit of this cleanup.

I withdraw this patch. Thank you for taking the time to explain this, 
its an important lesson about the difference between fixing issues in 
new code versus maintaining stability in existing interfaces.

Thanks,
Nirbhay