(cc'ing Peter) On 06.10.10 08:39:50, Paul Mundt wrote: > On Wed, Oct 06, 2010 at 02:27:36PM +0200, Robert Richter wrote: > > On 04.10.10 16:44:20, Matt Fleming wrote: > > > Introduce perf_pmu_name() helper function that returns the name of the > > > pmu. This gives us a generic way to get the name of a pmu regardless of > > > how an architecture identifies it internally, e.g. ARM uses an id > > > whereas SH currently uses a string. > > > > I rather want use here the solution we discussed earlier, simply > > including <asm/perf_event.h> and then access sh_pmu->name directly > > from oprofile. > > > No. Exposing sh_pmu generically is unacceptable. This is already I don't want to be the perf_pmu_name() discussion a show stopper for this patch set. We don't have a generic perf interface available now that allows us to detect the pmu type for sh cpus. I also don't see a name string as a final solution for pmu detection. So it will be more than just adding perf_pmu_name(). Until then, as we currently would only need the name for SH, I don't see something wrong here to include architectural interfaces from <asm/perf_event.h> directly by architectural code until a general solution is available. If you run a 'git grep include..asm/perf' this is common for other architectures. > centrally managed through perf, and if oprofile needs any additional > information then it needs to get that through the perf layer. We already > have the situation that effectively every architecture with perf support > implements a name string already, so making this part of the perf API > hardly seems like that big of a stretch. If the perf people are violently > opposed to this, then of course we can look at alternatives. I am not against adding the pmu name to the perf API. But the oprofile cpu_type strings are oprofile centric esp. for the userland. So these strings will remain part of oprofile. Also I don't think we want to polute the perf pmu names with it. > sh_pmu is created for use solely by the perf events code, we are not > going to have oprofile poking around in data structures it has no place > knowing anything about when 99% of everything else it is doing is already > abstracted cleanly through the perf events interfaces. Likewise for > special oprofile-specific APIs. So, I am also fine with implementing a generic perf_pmu_name() for sh and then derive the oprofile cpu_type string from it in the oprofile code. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html