Question: __u32 or u32 in BPF code

Question: __u32 or u32 in BPF code

[Donald Hunter]

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. 

Re: Question: __u32 or u32 in BPF code

[Andrii Nakryiko]

On Thu, Nov 3, 2022 at 5:37 AM Donald Hunter <donald.hunter@gmail.com> 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.