Tangential question from an embedded-but-not-Linux developer:
The structs use the types like __u32 or __u16. I know the kernel defines its own types for internal usage[1], but why redefine types exposed to user-space? Why not use C99 <stdint.h> types?
Is it only historical?
And why are they double-underscore?
[1] because... reasons? I never really understood why
Generally speaking when you interface with a c library you should use the same types it uses. So while you can like get by with `stdint.h`'s `uint64_t` on _most_ platforms you hurt portability.
Example:
This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void\`, and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while void\ and `long` are `uint32_t`, but in kernel land `void\*` is `uint64_t`).
Just like C11 Atomics can fail on ARM and PPC under some scenarios so the kernel doesn't use these as well.
Its my understand the Kernel supports more platforms then the C standardization committee xD
---
So the kernel likes to define its own primitives, and when you interface with it its is generally best to just use those definitions. Or if you want to use _standard_ types, you have to understand you are hurting portability.
> This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void` , and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while void\ and `long` are `uint32_t`, but in kernel land `voidx` is `uint64_t`).
In these cases, you just defined the variably-lengthed types (void* ) using the fixed-length types (uint64_t). This would just demonstrate that the fixed-length types are absolute, and IMO then good candidates to base absolute-sized types on. And yet that's still not good enough?
A bit of googling brings up the book Linux Device Drivers 3rd Ed (2005)[1], in which chap11 specifically addresses the topic of types. It argues against the usage of standard C types (int, long, etc) specifically because of their size variability. That's all well and good, but it doesn't make any mention of stdint.h!
A hypothesis comes up: maybe stdtint.h is meant to be a user-space header exposed by the system/compiler, and the kernel, having to be entirely bootstrapped, can't even depend on that? So it just redefines the types for itself? With the side-effect of exposing those to userspace at the API?
The problem with that idea is that the kernel cannot count on those types being consistently defined for all configurations, and cannot create its own definitions for the standard types. So the kernel/user interface must continue to be defined using kernel-specific types (__u16 and such).
What platforms are we talking about? Anything actually used by consumers or business or is it all just stuff that has esoteric support by hobbyists and those creating custom and reviving super old stuff.
I would imagine that if someone's platform doesn't support C11 at this point it pretty much hasn't been updated in 7 years and pretty much can't custom build GCC. I mean I know how to build GCC on a Sega Dreamcast so it has to be more esoteric than that.
Also, not supporting C11 probably also means not supporting lots of other things that modern applications might want like Vulkan, IPv6 or multiple threads.
The structs use the types like __u32 or __u16. I know the kernel defines its own types for internal usage[1], but why redefine types exposed to user-space? Why not use C99 <stdint.h> types?
Is it only historical?
And why are they double-underscore?
[1] because... reasons? I never really understood why