Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756412AbbHZHCH (ORCPT ); Wed, 26 Aug 2015 03:02:07 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:34513 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756373AbbHZHCF (ORCPT ); Wed, 26 Aug 2015 03:02:05 -0400 Date: Wed, 26 Aug 2015 09:02:00 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Johannes Berg , 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: <20150826070200.GA18443@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2762 Lines: 61 * Linus Torvalds wrote: > On Aug 25, 2015 21:49, "Ingo Molnar" 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. So the prctl() suggestion would address that worry, which would make it available essentially immediately, for any tool that cares. (And this would IMHO be a prctl() that kind of fits the interface, it does not feelt bolted on.) Internationalization could be done easily in a user-space library, by hash-tabling the English strings - for anyone who cares. It could be a simple free-form string->string translation library that gets strings added, it doesn't have to know about any context. > We've had this before. Some extension that is Linux-specific, and improved on > some small detail, and never gets used, and just cause pain. I think this time is different, especially with another interface variant we could use that I think addresses (most of your) concerns: > And the extended errors would be painful even in the kernel. We do compare for > specific error values. As does user space. There is a reason those values are > limited to a fairly small set of standard values, and system calls come with > documentation on which errors they can return. So my very first interface suggestion two years ago when this first came up was to decouple the error code from the string, i.e. to allow: return err_code(-EINVAL, "x86/perf: CPU does not support precise sampling"); ... which would return -EINVAL all the way - but would side-store the error string, for user-space that requests it. There would be no 'extended errno' space at all, dynamic or static, just the regular errno, and an optional string for user-space that wants to use it. This would make error codes still tightly clustered around a handful of main categories and there would be no change whatsoever to current error codes. Would you be fine with such an approach? > It may work for perf, but don't start thinking it works anywhere else Ok, will keep it perf (and scheduler) only. 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/