From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862Ab2INUF2 (ORCPT ); Fri, 14 Sep 2012 16:05:28 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:59963 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978Ab2INUF0 (ORCPT ); Fri, 14 Sep 2012 16:05:26 -0400 Date: Fri, 14 Sep 2012 22:05:18 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: Arnaldo Carvalho de Melo , David Ahern , linux-kernel@vger.kernel.org, Robert Richter Subject: Re: [PATCH 3/3 v2] perf tool: give user better message if precise is not supported Message-ID: <20120914200518.GA16872@gmail.com> References: <1347569955-54626-1-git-send-email-dsahern@gmail.com> <1347569955-54626-4-git-send-email-dsahern@gmail.com> <20120914054344.GB9043@gmail.com> <50531151.9020202@gmail.com> <20120914113617.GA13299@gmail.com> <5053186E.6000302@gmail.com> <20120914180013.GA27766@ghostprotocols.net> <1347646039.7172.66.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1347646039.7172.66.camel@twins> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote: > > > Understood and there have been suggestions on how to definitely state > > > what the kernel side did not like. I like Peter's last suggestion -- > > > something along the lines of clearing attr on a failure except the > > > offending setting. > > > > I think ws need to use a new bit > > Quite so, for all the reasons you list. But you like the > general idea? I wasn't sure I did, but it was the only thing I > could come up with that would sort of do what we need it to. > > The fact that you destroy the user input is awkward, I don't > think there's another syscall that behaves in this fashion. Destroying/clearing stuff looks really hacky. Why not use a single error status field, set via a long list of enum error constants, a 'perf errnos'? The only real problem with the kernel's syscall error code is that it's not wide enough for historic reasons, so we cannot just create our own errnos. But we can create our errors in the attr just fine and make them finegrained enough so that tooling can figure out what happened exactly when it gets a syscall error. Yes, that's old-fashioned technology, but it works. With time we could put some structure into the list of error IDs, to make it easily extensible yet grouped in some fashion, etc. Thanks, Ingo