On Tue, Mar 9, 2021 at 12:18 PM David Ahern <dsah...@gmail.com> wrote: > > On 3/9/21 1:02 PM, Steven Rostedt wrote: > > On Tue, 9 Mar 2021 12:53:37 -0700 > > David Ahern <dsah...@gmail.com> wrote: > > > >> Changing the order of the fields will impact any bpf programs expecting > >> the existing format > > > > I thought bpf programs were not API. And why are they not parsing this > > information? They have these offsets hard coded???? Why would they do that! > > The information to extract the data where ever it is has been there from > > day 1! Way before BPF ever had access to trace events. > > BPF programs attached to a tracepoint are passed a context - a structure > based on the format for the tracepoint. To take an in-tree example, look > at samples/bpf/offwaketime_kern.c: > > ... > > /* taken from /sys/kernel/debug/tracing/events/sched/sched_switch/format */ > struct sched_switch_args { > unsigned long long pad; > char prev_comm[16]; > int prev_pid; > int prev_prio; > long long prev_state; > char next_comm[16]; > int next_pid; > int next_prio; > }; > SEC("tracepoint/sched/sched_switch") > int oncpu(struct sched_switch_args *ctx) > { > > ... > > Production systems do not typically have toolchains installed, so > dynamic generation of the program based on the 'format' file on the > running system is not realistic. That means creating the programs on a > development machine and installing on the production box. Further, there > is an expectation that a bpf program compiled against version X works on > version Y.
This is not true.