On Thu, Feb 10, 2022 at 3:59 PM Delyan Kratunov <delyank@xxxxxx> wrote: > > On Thu, 2022-02-10 at 15:14 -0800, Alexei Starovoitov wrote: > > So adding > > _Static_assert(sizeof(type_in_skel) == const_size_from_kernel); > > to skel.h would force users to pick types that are the same > > both in bpf prog and in corresponding user space part. > > I'm not sure users have this much control over the definition of the types in > their program though. If a kernel and uapi typedef differ in size, this approach > would force the user to use kernel types for the entire program. > > If, for example, pid_t is a different size in glibc and the kernel, it would > force you out of using any glibc functions taking pid_t (and potentially all of > glibc depending on how entangled the headers are). pid_t is a great example, since its meaning is different in kernel and in user space. One is thread and another is process. static_assert will catch such issues and will force users to pick u64 and think through the type conversions. In kernel from pid_t -> u64 in bpf prog, and in user space pid_t -> u64 in skel. That would be an explicit action by users that hopefully make them think about the differences in size and semantics. > By normalizing to stdint types, we're saying that the contract represented by > the skel does not operate with either uapi or kernel types and it's up to you to > ensure you use the right one (or mix and match, if you can). It feels > fundamentally more permissive to different types of situations than forcing the > skel user to only use kernel types or refactor their program to isolate the > kernel type leakage to only the compilation unit using the skel. static_assert will force users to use compatible types, not kernel types.
