On Tue, Mar 19, 2024 at 12:20 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Mon, Mar 18, 2024 at 11:40 AM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote:
> >
> >
> > -int bpf_raw_tracepoint_open(const char *name, int prog_fd)
> > +int bpf_raw_tp_open(int prog_fd, struct bpf_raw_tp_opts *opts)
>
> ...
>
> > LIBBPF_1.4.0 {
> > global:
> > + bpf_program__attach_raw_tracepoint_opts;
> > + bpf_raw_tp_open;
>
> So far all api-s that accept opts have the "_opts" suffix.
> Why deviate from that?
_opts suffix in API functions was never really a universal rule. We
were adding xxx_opts() variant if we already had xxx() that didn't
have opts but already existed. But for new APIs where opts were added
from the very beginning we usually didn't do _opts() naming, e.g.,
bpf_token_create() accepts opts struct, but doesn't reflect opts in
the name.
In this case, given I decided to go with shorter "bpf_raw_tp_open()"
naming (as I found "bpf_raw_tracepoint_open_opts" way too verbose), I
decided to not add _opts suffix.
It's a different question on whether to do bpf_raw_tp_open() vs
keeping the original long name bpf_raw_tracepoint_open + adding _opts.
Let me address that in Eduard's email.
