On Thu, Nov 3, 2022 at 5:37 AM Donald Hunter <donald.hunter@xxxxxxxxx> wrote: > > Hi, > > Should BPF code be using UAPI types such as __u32 or is it considered > acceptable to use kernel types such as u32? I ask because the helper > definitions that come from libbpf use the UAPI __u32 style types, but > the bpf-helpers(7) man page refers to the kernel u32 style types. > > As I understand it, u32 et al are kernel internal type definitions that > should not leak into userspace which I believe extends to BPF > code. In order to use a kernel internal type, the BPF programmer would > need to define it themselves, or use a BTF generated vmlinux.h? Please > correct me if I am wrong, or oversimplifying things. > > I think it would be useful to include a statement about UAPI types and > usage in BPF code somewhere in the documentation. Once I have an answer > to the question above, I am happy to work on a contribution to the > documentation. > > A follow-on question is how to make things consistent across the UAPI > header files and the bpf-helpers(7) documentation. FWIW, libbpf's bpf_helper_defs.h is using __u32/__u64/etc. scripts/bpf_doc.py remaps everything uXX to __uXX for bpf_helper_defs, we can probably easily remap for man pages as well? But obviously u32/u64 looks a bit cleaner and nicer. And BPF code tends to be written in u32/u64 terms when using vmlinux.h, but only for internal types. When defining global variables, one has to be careful to not use u32/u64 because those types get exposed to user-space code. So I guess from consistency and POV of the least surprise, __u32/__u64 is preferrable. From aesthetics POV, u32/u64 are a bit nicer. Curious if anyone has a strong opinion, because I don't.
