On Tue, 2025-08-05 at 09:45 -0700, Alexei Starovoitov wrote:
> On Tue, Aug 5, 2025 at 6:04 AM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> wrote:
> >
> > Automatically enabling a perf event after attaching a BPF prog to it is
> > not always desirable.
> >
> > Add a new no_ioctl_enable field to struct bpf_perf_event_opts. While
> > introducing ioctl_enable instead would be nicer in that it would avoid
> > a double negation in the implementation, it would make
> > DECLARE_LIBBPF_OPTS() less efficient.
> >
> > Suggested-by: Jiri Olsa <jolsa@xxxxxxxxxx>
> > Co-developed-by: Thomas Richter <tmricht@xxxxxxxxxxxxx>
> > Signed-off-by: Thomas Richter <tmricht@xxxxxxxxxxxxx>
> > Signed-off-by: Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> > ---
Acked-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
[...]
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -499,9 +499,11 @@ struct bpf_perf_event_opts {
> > __u64 bpf_cookie;
> > /* don't use BPF link when attach BPF program */
> > bool force_ioctl_attach;
> > + /* don't automatically enable the event */
> > + bool no_ioctl_enable;
>
> The patch logic looks fine, but I feel the knob name is too
> implementation oriented.
> imo "dont_auto_enable" is more descriptive and easier
> to reason about.
>
> Let's wait for Eduard/Andrii reviews. This patch has to go
> via bpf trees first while the latter via perf.
Agree with Alexei,
something like "dont_enable" should be simpler to read.
