Hi Andrii, > Look at vmtest.sh under tools/testing/selftests/bpf, it handles > building kernel, selftests and spinning up qemu instance for running > selftests inside it. Thanks, this helps! > keeping generic u64 flags makes sense for the future, so I'd keep it. That makes sense, I'll keep the flags in that case. > But I also wanted to point out that this helper is logically in the > same family as bpf_probe_read_kernel/user and bpf_copy_from_user, etc, > where we have consistent pattern that first two arguments specify > destination buffer (so buf + len) and the remaining ones specify > source (in probe_read it's just an address, here it's tsk_addr). So I > wonder if it would be less surprising and more consistent to reorder > and have: > > buf, len, tsk, addr, flags > > ? Yeah, that looks better for consistency. Should I still keep the name as `bpf_access_process_vm`, or call it something else to be more consistent with the naming of the other bpf helpers? The benefit of the `bpf_access_process_vm` name is that it makes it obvious it is wrapping an existing function `access_process_vm`. Thanks for the feedback! Kenny
