Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756444AbbHZHUm (ORCPT ); Wed, 26 Aug 2015 03:20:42 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:38731 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756289AbbHZHUY (ORCPT ); Wed, 26 Aug 2015 03:20:24 -0400 Date: Wed, 26 Aug 2015 09:20:20 +0200 From: Ingo Molnar To: Johannes Berg Cc: Linus Torvalds , Thomas Gleixner , adrian.hunter@intel.com, Ingo Molnar , Borislav Petkov , Vince Weaver , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Andrew Morton , Peter Zijlstra , Alexander Shishkin , "H. Peter Anvin" , Stephane Eranian Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting Message-ID: <20150826072020.GA19081@gmail.com> References: <1440426780-27227-1-git-send-email-alexander.shishkin@linux.intel.com> <1440492739.2192.7.camel@sipsolutions.net> <20150825090252.GB22414@gmail.com> <20150825091740.GA23488@gmail.com> <1440495246.2192.13.camel@sipsolutions.net> <20150825100728.GA1820@gmail.com> <1440497981.2192.39.camel@sipsolutions.net> <20150826044948.GC14584@gmail.com> <1440572775.1932.1.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440572775.1932.1.camel@sipsolutions.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2264 Lines: 49 * Johannes Berg wrote: > On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote: > > > > No, the current MAX_ERRNO is probably not big enough if this scheme is successful, > > > and I don't see any reason why it wouldn't be successful: I think this feature > > > would be the biggest usability feature added to Linux system calls and to Linux > > > system tooling in the last 10 years or so. > > Don't be silly. It's a horrible idea. People would want to > > internationalize the strings etc, and nobody would use the extended > > versions anyway, since nobody uses raw system calls. > > That's a good point, and think that least in the netlink case it'd be much > better to say which attribute was the one that had an issue, and that has an > obvious binary encoding rather than encoding that in a string. So in older discussions about this I suggested a solution for that: also returning (in a channel separate from errnos) the byte offset to the field that caused the error, plus a string - and leaving errnos alone. This only matters for those (few) system calls that have a large attribute space: perf and some of the scheduler syscalls are such. With this scheme arbitrarily granular error handling can be implemented: - the laziest can just use the errno like usual, which catches 90% of the apps. - the somewhat sophisticated would print the human readable string (or a translation thereof). Would cover another 9%. (This percentage might increase over time, as the strings become more widely used.) - tools with a case of obsessive-compulsive perfectionism would use the structure offset to programmatically react to the error condition, and would use the human-readable string to explain the precise reason. Would cover another 1% of tools. ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust error handling is all about simplicity: if it's not simple, tools won't use it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/