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?
[...]
