On Thu, May 28, 2020 at 6:55 AM Joel Fernandes (Google) joel@joelfernandes.org wrote:
On a modern Linux distro, compiling the following program fails: #include<stdlib.h> #include<stdint.h> #include<pthread.h> #include<linux/sched/types.h>
You shouldn't include kernel headers in user space - that's the job of glibc and friends.
--- a/include/uapi/linux/sched/types.h +++ b/include/uapi/linux/sched/types.h @@ -4,9 +4,11 @@
#include <linux/types.h>
+#if defined(__KERNEL__) struct sched_param { int sched_priority; }; +#endif
This makes no sense.
The point of a 'uapi' header is to export things to user space. Yes, they sometimes mix kernel-internal thngs in there (because of how they were created by just moving kernel headers to the uapi directory), but that ' struct sched_param' is very much part of the very interface definition that that file is all about exporting.
So no, this patch is fundamentally wrong. It negates the whole point of having a uapi header at all.
The glibc-provided "<sched.h>" should have been where you got all these declarations and #defines from, and the point of the uapi file was always to help glibc (and other library implementations) get them from the kernel.
So why are you including kernel header files and mixing them with system-provided stuff?
Linus