Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756315AbbHZSlO (ORCPT ); Wed, 26 Aug 2015 14:41:14 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:32985 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbbHZSlN (ORCPT ); Wed, 26 Aug 2015 14:41:13 -0400 Date: Wed, 26 Aug 2015 11:41:11 -0700 From: Andrew Morton To: Ingo Molnar Cc: Johannes Berg , Linus Torvalds , Thomas Gleixner , adrian.hunter@intel.com, Ingo Molnar , Borislav Petkov , Vince Weaver , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Peter Zijlstra , Alexander Shishkin , "H. Peter Anvin" , Stephane Eranian Subject: Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting Message-Id: <20150826114111.01675d8eadda78d82933d8a5@linux-foundation.org> In-Reply-To: <20150826072656.GA19305@gmail.com> References: <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> <20150826072656.GA19305@gmail.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 44 On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > ... 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. > > And note that it needs to be 'simple' in two places for usage to grow naturally: > > - the usage site in the kernel > - the tooling side that recovers the information. > > That's why I think that such a form: > > return err_str(-EINVAL, "x86/perf: CPU does not support precise sampling"); > > is obviously simple on the kernel side as it returns -EINVAL, and is very simple > on the tooling side as well, if we are allowed to extend prctl(). > Is this whole thing overkill? As far as I can see, the problem which is being addressed only occurs in a couple of places (perf, wifi netlink handling) and could be addressed with some local pr_debug statements. ie, #define err_str(e, s) ({ if (debugging) pr_debug("%s:%d: error %d (%s)", __FILE__, __LINE__, e, s); e; }) (And I suppose that if this is later deemed inadequate, err_str() could be made more fancy). IOW, do we really need some grand kernel-wide infrastructural thing to adequately address this problem? -- 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/