Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752148AbbGIIK1 (ORCPT ); Thu, 9 Jul 2015 04:10:27 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:38177 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261AbbGIIKQ (ORCPT ); Thu, 9 Jul 2015 04:10:16 -0400 Date: Thu, 9 Jul 2015 10:10:11 +0200 From: Ingo Molnar To: Adrian Hunter Cc: Peter Zijlstra , Arnaldo Carvalho de Melo , Andy Lutomirski , Vince Weaver , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Jiri Olsa , Stephane Eranian , Borislav Petkov , Alexander Shishkin , Andi Kleen Subject: Re: [RFC PATCH] perf: Provide status of known PMUs Message-ID: <20150709081011.GA31953@gmail.com> References: <1436428080-3098-1-git-send-email-adrian.hunter@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1436428080-3098-1-git-send-email-adrian.hunter@intel.com> 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: 2008 Lines: 62 * Adrian Hunter wrote: > Known PMUs may not be present for various reasons. > Provide a way for the user to know what the reason > is. > > A bus attribute is created for each known PMU beneath > a group "known_pmus". The attribute name is the same > as the PMU name. The value is a string consisting of > one or, optionally, two parts: a canonical part, and > a driver specific part. If there are two parts, they > are separated by " - ". The canonical part is one of: > > Supported > Driver error > Driver not loaded > Driver not in kernel config > Not supported by kernel > Not supported by hardware > Wrong vendor > Wrong architecture > Unknown status Very nice! > Example: > > $ cat /sys/bus/event_source/known_pmus/intel_pt > Supported So I only have naming nits. 'Supported' is a bit ambiguous, because it could mean that the PMU is supported but the driver is not active. How about 'Enabled'? I'd also make the strings more unambiguously structured, something like: Enabled Disabled: Driver error Disabled: Driver not loaded Disabled: Driver not in kernel config Disabled: Not supported by the kernel Disabled: Not supported by the hardware Disabled: Not supported by the hardware vendor Disabled: Not supported by the the architecture Disabled: Unknown status (Note the small changes I did to the text in some places.) Also note that I'd suggest not enumerating all the error reasons rigidly - just have a single error code, but a free flowing error string that is provided by the low level driver (and maybe strdup()-ed by the core). That way you can provide very specific error descriptions, without having to change the core every time you need a new category. Agreed? 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/