From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757925AbcASXwN (ORCPT ); Tue, 19 Jan 2016 18:52:13 -0500 Received: from mail-ob0-f173.google.com ([209.85.214.173]:36121 "EHLO mail-ob0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754244AbcASXwJ convert rfc822-to-8bit (ORCPT ); Tue, 19 Jan 2016 18:52:09 -0500 MIME-Version: 1.0 In-Reply-To: <20160119104051.21d8e2ac@endymion.delvare> References: <9d1eb8634669ef09334c7e792eb21f20b320a07b.1453150613.git.luto@kernel.org> <20160119085426.7d4b1f8b@endymion.delvare> <20160119083633.GD7192@pali> <20160119100303.73cf6256@endymion.delvare> <20160119090736.GF7192@pali> <20160119104051.21d8e2ac@endymion.delvare> From: Andy Lutomirski Date: Tue, 19 Jan 2016 15:51:49 -0800 Message-ID: Subject: Re: [PATCH v2 3/3] dmi: Make dmi_walk and dmi_walk_early return real error codes To: Jean Delvare Cc: =?UTF-8?Q?Pali_Roh=C3=A1r?= , Andy Lutomirski , platform-driver-x86@vger.kernel.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 19, 2016 at 1:40 AM, Jean Delvare 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