Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756415AbbHZHhD (ORCPT ); Wed, 26 Aug 2015 03:37:03 -0400 Received: from s3.sipsolutions.net ([5.9.151.49]:43715 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751898AbbHZHhB (ORCPT ); Wed, 26 Aug 2015 03:37:01 -0400 Message-ID: <1440574589.1932.5.camel@sipsolutions.net> Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting From: Johannes Berg To: Ingo Molnar 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 Date: Wed, 26 Aug 2015 09:36:29 +0200 In-Reply-To: <20150826072020.GA19081@gmail.com> (sfid-20150826_092023_907723_DF3AA08F) 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> <20150826072020.GA19081@gmail.com> (sfid-20150826_092023_907723_DF3AA08F) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2105 Lines: 43 On Wed, 2015-08-26 at 09:20 +0200, Ingo Molnar wrote: > > 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. I was considering, at least in this case, to forgo the string entirely - that makes it use less space in the kernel (no need for all those strings) and completely avoids the discussion about translation etc., while still being entirely sufficient for the debugging I have in mind. > This only matters for those (few) system calls that have a large attribute space: > perf and some of the scheduler syscalls are such. As I'm saying, netlink is that in a way as well :) Except it's not a syscall per se, since it's layered behind a message passing interface. > 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.) > Well, if the apps were to be extended trivially to print, in the netlink case, the attribute with an error, that'd help debugging significantly - not much need for a string in that case. But I'll agree that it's a more special case than the perf case you're looking at where you have things like "your hardware doesn't support this" which obviously isn't really tied to some argument directly. johannes -- 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/