Re: [PATCH v2 00/27] Constify tool pointers

[Ian Rogers <irogers@google.com>]

On Fri, Jun 28, 2024 at 10:25 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Wed, Jun 26, 2024 at 01:36:02PM -0700, Ian Rogers wrote:
> > struct perf_tool provides a set of function pointers that are called
> > through when processing perf data. To make filling the pointers less
> > cumbersome, if they are NULL perf_tools__fill_defaults will add
> > default do nothing implementations.
> >
> > This change refactors struct perf_tool to have an init function that
> > provides the default implementation. The special use of NULL and
> > perf_tools__fill_defaults are removed. As a consequence the tool
> > pointers can then all be made const, which better reflects the
> > behavior a particular perf command would expect of the tool and to
> > some extent can reduce the cognitive load on someone working on a
> > command.
>
> I thought you actually wanted to make the tool const (rodata) but it
> seems you leave it as is but treat it as const.

So I think that is a next step on top of these changes but it would
need something a bit special as we want to default initialize some
fields but then initialize others. Something like (which wouldn't
work):

.tool = DEFAULT_TOOL_STUBS({
               .sample         = process_sample_event,
               .fork           = perf_event__process_fork,
               .exit           = perf_event__process_exit,
               .comm           = perf_event__process_comm,
               .namespaces     = perf_event__process_namespaces,
               .mmap           = build_id__process_mmap,
               .mmap2          = build_id__process_mmap2,
               .itrace_start   = process_timestamp_boundary,
               .aux            = process_timestamp_boundary})

Being const is just saying hey all these event callbacks aren't going
to mutate the tool, something I wanted to rule out as part of a change
I'm working on.

> I'm curious if we can change the event delivery code something like:
>
>   if (tool->func)
>       tool->func(...);
>   else
>       stub_func(...);
>
> Then probably we don't need to touch the tool and make it const.
> Thoughts?

It works but the approach needs to change all tool func callers. I
think it is also more obvious as an API to have a default value and
override it, rather than giving special properties to NULL that
callers should adhere to - we're doing a kind of poor man's virtual
method dispatch and you wouldn't typically expect a NULL check as part
of that.

Thanks,
Ian

> Thanks,
> Namhyung