Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752552AbbGIIrm (ORCPT ); Thu, 9 Jul 2015 04:47:42 -0400 Received: from mga01.intel.com ([192.55.52.88]:50770 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbbGIIr1 (ORCPT ); Thu, 9 Jul 2015 04:47:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,438,1432623600"; d="scan'208";a="743537550" Message-ID: <559E3487.1000600@intel.com> Date: Thu, 09 Jul 2015 11:44:55 +0300 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ingo Molnar 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 References: <1436428080-3098-1-git-send-email-adrian.hunter@intel.com> <20150709081011.GA31953@gmail.com> In-Reply-To: <20150709081011.GA31953@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2533 Lines: 73 On 09/07/15 11:10, Ingo Molnar wrote: > > * 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.) OK > > 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? Drivers can optionally provide a string - the optional second part described above. For example: $ cat /sys/bus/event_source/known_pmus/intel_pt Disabled: Not supported by the hardware - ToPA output is not supported on this CPU Having a finite set of categories allows software to interpret the string for purposes other than displaying it. Having an optional second part allows drivers to detail anything else. -- 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/