Hi, On 1/25/21 11:57 AM, Andy Shevchenko wrote: > On Mon, Jan 25, 2021 at 9:37 AM Ike Panhc <ike.pan@xxxxxxxxxxxxx> wrote: >> >> On 1/17/21 3:49 AM, Andy Shevchenko wrote: >>> On Wed, Jan 13, 2021 at 8:23 PM Barnabás Pőcze <pobrn@xxxxxxxxxxxxxx> wrote: >>>> >>>> Consumers can differentiate an error from a successful read much more >>>> easily if the read() call fails with the appropriate errno instead of >>>> returning a magic string like "-1". >>> >>> Is user space ready for this (for the record, it seems an ABI breakage)? >>> >> >> read() and getting errno looks sysfs/driver broken to me. I think >> if button/method is not available, it's better to be something like >> sysfs_emit(buf, "%d\n", -ENODEV) > > Either way it will be an ABI breakage. True any change here will be an ABI breakage, but I really do not expect anything to be dependent on this weird behavior of returning errors by writing some magic value to the buffer, rather then just error-ing out of the read() call. The kernel-convention here clearly is to make the read() syscall fail with -ESOMETHING on errors. So I see this as making the driver conform to the expected sysfs API behavior. Since this change is nicely split out into a separate patch, we can always revert it if it turns out there actually is something depending on this. But again I see that as highly unlikely. Regards, Hans
