From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 24D1BA88 for ; Fri, 4 Aug 2017 14:22:39 +0000 (UTC) Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 447053F8 for ; Fri, 4 Aug 2017 14:21:46 +0000 (UTC) Date: Fri, 4 Aug 2017 10:20:33 -0400 From: Theodore Ts'o To: Julia Lawall Message-ID: <20170804142033.budoksvyhbphxmun@thunk.org> References: <20170804022639.p27oliuinqqatar2@thunk.org> <20170804132704.73c49b64@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Andy Lutomirski , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Aug 04, 2017 at 07:13:10AM +0200, Julia Lawall wrote: > I did some work on a semantic patch for collecting the error codes > returned by all of the system class. Things were going fairly well until > I discovered that is fairly common near the user level to return error > codes in reference parameters rather than by direct returns, and that > meant that I was going to have to duplicate my entire rule set. I also > observed that the documentation is not always that precise. It will say > typically returns -E1, -E2, -E3, and may return other stuff, so in that > case there is less to check. Yeah, including potential new error returns as "changes to the ABI/API" is probably simply not practical. Adding a return for, say, ENOMEM instead of causing a kernel oops is not something that needs to be debated on the linux-api mailing list! I recall, many years ago, an executive being indignant because Linux was returning some error code for some syscall operation involving network file system because it returned an network-related errno that was not explicitly listed in POSIX for a file system related syscall, and demanded that we fix the problem. I had to gently point out to said gentleman (since I was working for the Linux Foundation at the time and he worked for a platinum sponsor :-) that POSIX as a blanket statment allows confirming implementations' system calls to return additional error codes as necessary. I think people are much more concerned when there is a new system call, or a new flag added to a core syscall (e.g., O_TMPFILE). I suspect that we required all new device ioctls and new flags to device ioctls to get the linux-api@ treatment that we would get mass resistance and the workload would not be practical. And this list doesn't even consider new sysfs files, new tracepoints, etc., etc. Although technically speaking this is all "API's" I think we need to pick our battles and start with a tractable subset of the problem... - Ted