include/linux/sysctl.h needs linux/compiler.h

Adding patch below solves the problem (yes, I know, userspace is not supposed to use kernel headers...)

Quoted 1 line · Kevin P. Fleming

Adding patch below solves the problem (yes, I know, userspace is not supposed to use kernel headers...)

So why do you try it anyway?

Changes during 2.5.70 added _user tags to various bits in include/linux/sysctl.h. __user is defined in linux/compiler.h, which is included by linux/kernel.h but only if __KERNEL__ is defined. Compiliing uClibc against 2.5.70 fails because __user__ is not defined.

Adding patch below solves the problem (yes, I know, userspace is not supposed to use kernel headers...)

Quoted 16 lines · Kevin P. Fleming

Changes during 2.5.70 added _user tags to various bits in include/linux/sysctl.h. __user is defined in linux/compiler.h, which is included by linux/kernel.h but only if __KERNEL__ is defined. Compiliing uClibc against 2.5.70 fails because __user__ is not defined.

Adding patch below solves the problem (yes, I know, userspace is not supposed to use kernel headers...)

include/linux/sysctl.h renamed from include/linux/sysctl.h~ +1 -0

@@ -27,6 +27,7 @@
 #include <linux/kernel.h>
 #include <linux/types.h>
 #include <linux/list.h>
+#include <linux/compiler.h>
 

include/linux/sysctl.h line 32

Quoted 1 line

include/linux/sysctl.h renamed from include/linux/sysctl.h~ +0 -0

 struct file;

linux/kernel.h includes <linux/compiler.h>.

See the beginning of my message... it only does so if _KERNEL_ is defined. Since other header files also directly include compiler.h even though they already include kernel.h, I didn't think this was an unreasonable solution (i.e. they must have done it for the same reason, since there are comments specifically about including compiler.h for "__user").

Quoted 7 lines · Kevin P. Fleming

See the beginning of my message... it only does so if _KERNEL_ is defined. Since other header files also directly include compiler.h even though they already include kernel.h, I didn't think this was an unreasonable solution (i.e. they must have done it for the same reason, since there are comments specifically about including compiler.h for "__user").

Thats a bigger problem and should be solved like ( imho ) with higher level of kernel api which provides userspace apps kernel level operations.

Right. But until such time as that happens (even if started today that's many months away), real world libraries need to be compiled to be used against the new kernel.

Quoted 4 lines · Kevin P. Fleming

Right. But until such time as that happens (even if started today that's many months away), real world libraries need to be compiled to be used against the new kernel.

Yes I reported to binutils hackers that this change broke binutils ( + glibc ) but kernel guys just say "do not include kernel headers in userspace" .

Oh, I saw that discussion. I fully agree. If I can help the process of creating a sanitized userspace set of kernel headers I'll be happy to.

In the meantime, a small change to a kernel header, that provides _zero_ functional difference to the kernel itself (it's only there for source code checkers, as best I can tell) shouldn't break existing userspace libraries.

Quoted 3 lines · Kevin P. Fleming

Oh, I saw that discussion. I fully agree. If I can help the process of creating a sanitized userspace set of kernel headers I'll be happy to.

Quoted 4 lines

In the meantime, a small change to a kernel header, that provides _zero_ functional difference to the kernel itself (it's only there for source code checkers, as best I can tell) shouldn't break existing userspace libraries.

Fully ACK.

The solution is to have a set of API headers that userspace can use, and that the kernel headers in turn include.

Problem now (as usual), is that even though I and a few others did offer to help or organise help if one kernel hacker is willing to take the lead, nobody responded, so I guess we will not see this any time soon.