On 10/30/19 11:32 PM, Alexei Starovoitov wrote:
The bpf program type raw_tp together with 'expected_attach_type' was the most appropriate api to indicate BTF-enabled raw_tp programs. But during development it became apparent that 'expected_attach_type' cannot be used and new 'attach_btf_id' field had to be introduced. Which means that the information is duplicated in two fields where one of them is ignored. Clean it up by introducing new program type where both 'expected_attach_type' and 'attach_btf_id' fields have specific meaning.
Hm, just for my understanding, the expected_attach_type is unused for tracing so far. Are you aware of anyone (bcc / bpftrace / etc) leaving uninitialized garbage in there? Just seems confusing that we have all the different tracing prog types and now adding yet another one as BPF_RPOG_TYPE_TRACING which will act as umbrella one and again have different attach types some of which probably resemble existing tracing prog types again (kprobes / kretprobes for example). Sounds like this new type would implicitly deprecate all the existing types (sort of as we're replacing them with new sub-types)? True that k[ret]probe expects pt_regs whereas BTF enabled program context will be the same as raw_tp as well, but couldn't this logic be hidden in the kernel e.g. via attach_btf_id as well since this is an opt-in? Could the fentry/fexit be described through attach_btf_id as well?
In the future 'expected_attach_type' will be extended with other attach points that have similar semantics to raw_tp. This patch is replacing BTF-enabled BPF_PROG_TYPE_RAW_TRACEPOINT with prog_type = BPF_RPOG_TYPE_TRACING expected_attach_type = BPF_TRACE_RAW_TP attach_btf_id = btf_id of raw tracepoint inside the kernel Future patches will add expected_attach_type = BPF_TRACE_FENTRY or BPF_TRACE_FEXIT where programs have the same input context and the same helpers, but different attach points. Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx> Acked-by: Andrii Nakryiko <andriin@xxxxxx>
Thanks, Daniel
