Thread (30 messages) 30 messages, 4 authors, 2023-02-04

Re: [PATCH v5 10/15] perf jevents: Generate metrics and events as separate tables

From: John Garry <john.g.garry@oracle.com>
Date: 2023-02-01 18:30:27
Also in: linux-arm-kernel, linux-perf-users, lkml

On 30/01/2023 22:54, Ian Rogers wrote:
quoted
This is almost identical to generated perf_pmu__find_events_table(),
except we return a pmu_metrics_table * (instead of a pmu_events_table *)
and also return the metric table member (instead of event table). But
the definitions are:

/* Struct used to make the PMU event table implementation opaque to
callers. */
struct pmu_events_table {
          const struct compact_pmu_event *entries;
          size_t length;
};

/* Struct used to make the PMU metric table implementation opaque to
callers. */
struct pmu_metrics_table {
          const struct compact_pmu_event *entries;
          size_t length;
};

Those structs are defined to be the same thing, so I am failing to see
the point in a) separate structure types b) why so much duplication

As for b), I know that they are generated and the python code may be
simpler this way (is it?), but still...
Agreed. The point is to separate the two tables for the typing at the
API layer, internally the representation is the same. When we decode
one we get a pmu_event and the other we get a pmu_metric, so we don't
want to allow the tables to be switched - hence two types.
I do see the advantage of stronger types but it does seem a bit odd to 
achieve it like this.

Thanks,
John
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help