On Thu, Jan 18, 2024 at 11:50 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Wed, 2024-01-17 at 14:33 -0800, Andrii Nakryiko wrote:
> [...]
>
> > - for kprobes, we always accept `struct pt_regs *`, as that's what
> > actually is passed as a context to any kprobe program;
> > - for perf_event, we resolve typedefs down to actual struct type and
> > accept `struct {pt_regs,user_pt_regs,user_regs_struct} *` if kernel
> > architecture actually defines `bpf_user_pt_regs_t` as an alias for
> > the corresponding struct;
> > otherwise, canonical `struct bpf_perf_event_data *` is expected;
> > - for raw_tp/raw_tp.w programs, `u64/long *` are accepted, as that's
> > what's expected with BPF_PROG() usage; otherwise, canonical
> > `struct bpf_raw_tracepoint_args *` is expected;
> > - tp_btf supports both `struct bpf_raw_tracepoint_args *` and `u64 *`
> > formats, both are coded as expections as tp_btf is actually a TRACING
> > program type, which has no canonical context type;
> > - iterator programs accept `struct bpf_iter__xxx *` structs, currently
> > with no further iterator-type specific enforcement;
> > - fentry/fexit/fmod_ret/lsm/struct_ops all accept `u64 *`;
> > - classic tracepoint programs, as well as syscall and freplace
> > programs allow any user-provided type.
>
> The "arg:..." rules become quite complex, do you plan to document
> these either in kernel rst's or as doc-strings for relevant macros?
They are meant to be natural extensions of existing expectations, so
users hopefully wouldn't need to worry about them. But you are right,
global subprogs are not documented at all. But no, I didn't have
immediate plans to document them, maybe some time later.
>
> [...]
>
>
