Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752991Ab0G0RwV (ORCPT ); Tue, 27 Jul 2010 13:52:21 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:59451 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752947Ab0G0RwT (ORCPT ); Tue, 27 Jul 2010 13:52:19 -0400 Message-ID: <4C4F1CBB.7040003@linux.vnet.ibm.com> Date: Tue, 27 Jul 2010 10:51:55 -0700 From: Corey Ashford User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Robert Richter CC: Lin Ming , Ingo Molnar , Johannes Berg , Peter Zijlstra , Greg KH , Frederic Weisbecker , Paul Mundt , "eranian@gmail.com" , "Gary.Mohr@Bull.com" , "arjan@linux.intel.com" , "Zhang, Yanmin" , Paul Mackerras , "David S. Miller" , Russell King , Arnaldo Carvalho de Melo , Will Deacon , Maynard Johnson , Carl Love , Kay Sievers , lkml , Thomas Gleixner , Steven Rostedt Subject: Re: [RFC][PATCH v1 02/15] perf: export generic hardware events via sysfs References: <1279797142.20942.83.camel@minggr.sh.intel.com> <20100723104412.GA26154@erda.amd.com> <1280197103.24607.61.camel@minggr.sh.intel.com> <20100727082749.GK26154@erda.amd.com> In-Reply-To: <20100727082749.GK26154@erda.amd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1435 Lines: 40 On 07/27/2010 01:27 AM, Robert Richter wrote: > On 26.07.10 22:18:23, Lin Ming wrote: > >>>> /sys/devices/system/cpu/cpu0/events >>>> |-- L1-dcache-load-misses >>>> | |-- config >>>> | `-- type > > vs. > >>> |-- L1-dcache-load-misses ===> event name >>> | `-- id ===> event id > >>> This is very simple and flexible and solves the original problem too. >> >> Yeah, this is flexible. I'll think about this closely. > > The thing is, if you start introducing the config/type i/f, we will > stick with it for a long time. I want to avoid this from the > beginning. > > Using an id only would work with your current implementation too, you > only need to maintain an id -> config/type mapping, maybe in some > private data section, without exporting it to userspace. Now that I understand that the sysfs id essentially points to a kernel data structure, I like this idea a lot. Before I was thinking that you were trying to place a lot of info into the id itself. The only downside I see, and maybe it's a very minor one, is that you'll no longer have the ability to specify an event without specifying a sysfs path... there's no other mechanism. - Corey -- 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/