> On 11 Apr 2019, at 04:19, Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx> wrote: > > On Wed, 10 Apr 2019 20:50:25 +0100, Jiong Wang wrote: >> Enable BPF_F_TEST_RND_HI32 for all existing bpf selftests or other >> independent tests could involve quite a few changes to make sure all bpf >> prog load places has BPF_F_TEST_RND_HI32 set. >> >> Given most of the tests are using libbpf, this patch introduces a new >> global variable "libbpf_test_mode" into libbpf, once which is set, all bpf >> prog load issued through libbpf will have BPF_F_TEST_RND_HI32 set >> automatically, this could minimize changes required from testsuite. >> >> The other way might be introducing new load function like >> "bpf_prog_test_load", which will set BPF_F_TEST_RND_HI32. But there are >> several prog load APIs, and we need minor changes on some parameters. >> >> The global variable approach seems to be a proper first step for easy >> testsuite porting. >> >> Signed-off-by: Jiong Wang <jiong.wang@xxxxxxxxxxxxx> > > Can we perhaps make it per-object by setting it after > bpf_object__open() but before bpf_object__load(), or add > it to struct bpf_object_open_attr? Not sure I followed the meaning correctly. My read is you mean it would better if there is more accurate and fine control on this feature, especially if prog_flags could become an API parameter during file/obj/prog load? As mentioned in the cover letter, I tried to implement bpf_prog_test_load In parallel with existing bpf_prog_test_run, but then found there are also similar APIs for bpf_object__open, and raw insn load “bpf_load_progams” etc and they may involve extending bpf_prog_load_attr/bpf_load_program_attr etc. I thought the change is a little bit heavy. I could go further if it is thought to be the correct way or there is any other suggestion on nicely passing “prog_flags” to low level bpf syscall in libbpf. Regards, Jiong