On Wed, Apr 15, 2015 at 01:50:42PM -0700, Sukadev Bhattiprolu wrote:
SNIP
>
> |
> | - to add an ABI to support those vendor files
> |
> | And those are IMHO five good technical reasons to disagree with your
> | approach.
> |
> | My suggestion to resolve the technical objections and lift the NAK
> | would be:
> |
> | - to add the tables to the source code, in a more human readable
> | format and (optionally) structure the event names better into a
> | higher level hierarchy, than the humungous linear dumps with no
> | explanations that you propose - while still supporting the 'raw'
> | vendor event names you want to use, for those people who are used
> | to them.
> |
>
> A bit confused.
>
> Have the JSON files in the tree and generate the C structure during
> build?
>
> Or, ditch the JSON files and add something like this in say,
> tools/perf/arch/powerpc/util/power8-events.h?
>
> static const struct events power8_events[] = {
> [ 0 ] = {
> .name = "PM_1LPAR_CYC",
> .code = 0x1f05e,
> .brief_desc = " "Number of cycles in single lpar mode. All threads in
> the core are assigned to the same lpar,",
> .public_desc = "Number of cycles in single lpar mode.,",
> },
>
> If we have the JSON files, would the 'make install' put the JSON files
> in ~/.cache/pmu-events or in a standard location?
IIUC the intention is not to have external event data files
but have them compiled into perf binary.. like we could have
JSON with events description under perf source and build it
into 'struct perf_pmu_alias' data duting the build..
the pmu.c alias logic would need a little adjustments,
but it seems doable to me
jirka
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
