On Tue, Jan 19, 2016 at 1:40 AM, Jean Delvare <jdelvare@xxxxxxx> wrote: > On Tue, 19 Jan 2016 10:07:36 +0100, Pali Rohár wrote: >> On Tuesday 19 January 2016 10:03:03 Jean Delvare wrote: >> > Hi Pali, >> > >> > On Tue, 19 Jan 2016 09:36:33 +0100, Pali Rohár wrote: >> > > On Tuesday 19 January 2016 08:54:26 Jean Delvare wrote: >> > > > > @@ -978,11 +978,11 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void *), >> > > > > u8 *buf; >> > > > > >> > > > > if (!dmi_available) >> > > > > - return -1; >> > > > > + return -ENOENT; >> > > > >> > > > -ENOSYS would seem more appropriate? >> > > >> > > IIRC -ENOSYS is for non implemented syscalls. >> > >> > I can see a lot of -ENOSYS in include/linux/*.h returned by stubs when >> > a specific subsystem is not included. Not related to syscalls at all. >> > This is what lead to my suggestion. >> >> https://lkml.org/lkml/2014/8/22/492 > > Thanks for the pointer, I wasn't aware of that. > > It really should be documented. No, checkpatch.pl isn't documentation. > > Also the commit sadly doesn't say why using ENOSYS in other contexts is > considered a bad thing. What actual trouble did it cause? The trouble is that user code likes to assume that, when a syscall returns -ENOSYS, that syscall isn't implemented. Letting ENOSYS leak out to userspace via a syscall that *is* implemented can confused things. > > Are the current presumably incorrect uses of ENOSYS ultimately going to > be fixed? If not, I see no point in preventing other use cases. We at least want to prevent it from newly introduced syscalls. I'll try to clean up the docs. --Andy -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
