(2015/03/22 1:02), Alexei Starovoitov wrote: > On 3/21/15 5:14 AM, Masami Hiramatsu wrote: >> (2015/03/21 8:30), Alexei Starovoitov wrote: >>> >>> Note, kprobes are _not_ a stable kernel ABI, so bpf programs attached to >>> kprobes must be recompiled for every kernel version and user must supply correct >>> LINUX_VERSION_CODE in attr.kern_version during bpf_prog_load() call. >>> >> >> Would you mean that the ABI of kprobe-based BPF programs? Kprobe API/ABIs >> (register_kprobe() etc.) are stable, but the code who use kprobes certainly >> depends the kernel binary by design. So, if you meant it, BPF programs must >> be recompiled for every kernel binaries (including configuration changes, >> not only its version). > > yes. I mainly meant that bpf+kprobe programs must be recompiled > for every kernel binary. Hmm, if so, as we do in perf (and systemtap too), you'd better check kernel's build-id instead of the kernel version when loading the BPF program. It is safer than the KERNEL_VERSION_CODE. > But you're incorrect saying that register_kprobe API is stable. > It's equally kernel dependent. > register_kprobe(struct kprobe *p) is export_gpl, but it takes > kernel internal 'struct kprobe' and it's not declared in uapi header. > Prototype of kprobe_handler_t is also kernel internal, so whoever > is using kprobes must recompile their code every time. > If we want, we can change register_kprobe function name to something > else. Just like kernel modules cannot expect that exported symbols > will stay around from version to version. We don't care when we > break out of tree modules. Indeed the register_kprobe (and other kprobe related functions) should not be treated as a stable userland exported ABI/API. :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
