Em Thu, Nov 30, 2017 at 01:51:15PM -0800, Alexei Starovoitov escreveu: > On 11/30/17 11:00 AM, Arnaldo Carvalho de Melo wrote: > > > Instead of sinking all future bpf_attr's backward compatibility > > > requirements to sys_bpf, I would push it up to its own BPF_* command > > > helper which has a better sense of its bpf_attr, i.e. push it up > > > to bpf_create_map_node() and bpf_load_program_name() in this case. > > Humm, we could try that approach, but the one in this patch seemed good > > enough. > > > > And after all if the first syscall() invokation, with the latest kernel > > and latest tooling will work, right? > > I agree with Martin and I also don't think it will work to push > logic of all bpf commands into single sys_bpf syscall wrapper.
Sure, that was just a POC, I'll work on something that takes into account what you guys pointed out. > This logic will become more and more complex over time. > Like this case really belongs in bpf_create_map() which is a wrapper > on top of single BPF_CREATE_MAP command. > Note it's the first time we're facing this 'new libbpf.a running on > top of old kernel' issue and should be very careful adding such > fallback code to the generic bpf library, since all the selftests/bpf/ > are using this lib and relying on excepted behavior. Right, tools/perf/ uses it as well and relies on its continued functioning. > We don't want tests that want to test the latest kernel feature all of > a sudden pass on old kernel that doesn't have it. Sure, neither do I :-) > To some degree perf and selftests/bpf needs are diverging here, > so adding #ifdef to libbpf.a to match testcase expectations may be > necessary. But this is not just testcase expectations, the usecase is someone wanting to use a newer tool, with perhaps some new features of interest that don't depend on changes in the kernel, in an older kernel on a system where updating it is not possible or desirable. - Arnaldo
