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...)
--- linux-2.5/include/linux/sysctl.h~ Sat May 31 08:52:49 2003
+++ linux-2.5/include/linux/sysctl.h Sat May 31 09:04:29 2003
@@ -27,6 +27,7 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/list.h>
+#include <linux/compiler.h>
struct file;
On Sat, May 31, 2003 at 09:18:44AM -0700, Kevin P. Fleming wrote:
> Adding patch below solves the problem (yes, I know, userspace is not
> supposed to use kernel headers...)
So why do you try it anyway?
Christoph Hellwig wrote:
> On Sat, May 31, 2003 at 09:18:44AM -0700, Kevin P. Fleming wrote:
>
>>Adding patch below solves the problem (yes, I know, userspace is not
>>supposed to use kernel headers...)
>
>
> So why do you try it anyway?
>
Until someone addresses this issue with a permanent fix, is there
another choice? How can any userspace library that needs to issue
syscalls compile against the existing sysctl.h without this change? I'm
open to suggestions, obviously this was a quick and dirty fix (copied
from other existing headers in .../linux already, which is certainly no
excuse).
On Saturday 31 May 2003 19:18, Kevin P. Fleming wrote:
> 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...)
>
> --- linux-2.5/include/linux/sysctl.h~ Sat May 31 08:52:49 2003
> +++ linux-2.5/include/linux/sysctl.h Sat May 31 09:04:29 2003
> @@ -27,6 +27,7 @@
> #include <linux/kernel.h>
> #include <linux/types.h>
> #include <linux/list.h>
> +#include <linux/compiler.h>
>
> struct file;
linux/kernel.h includes <linux/compiler.h>.
Regards,
/ismail
ismail (cartman) donmez wrote:
> On Saturday 31 May 2003 19:18, Kevin P. Fleming wrote:
>
>>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...)
>>
>>--- linux-2.5/include/linux/sysctl.h~ Sat May 31 08:52:49 2003
>>+++ linux-2.5/include/linux/sysctl.h Sat May 31 09:04:29 2003
>>@@ -27,6 +27,7 @@
>> #include <linux/kernel.h>
>> #include <linux/types.h>
>> #include <linux/list.h>
>>+#include <linux/compiler.h>
>>
>> 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").
On Saturday 31 May 2003 23:32, Kevin P. Fleming wrote:
> 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.
Regards,
/ismail
ismail (cartman) donmez wrote:
> On Saturday 31 May 2003 23:32, Kevin P. Fleming wrote:
>
>>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.
On Sunday 01 June 2003 00:08, Kevin P. Fleming wrote:
> 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" .
Regards,
/ismail
ismail (cartman) donmez wrote:
> On Sunday 01 June 2003 00:08, Kevin P. Fleming wrote:
>
>
>>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.
If it's going to, then we should just go ahead and break everything and
get it done right. It's late in the 2.6 game, but the first few steps on
the path have already been taken.
On Sunday 01 June 2003 02:37, Kevin P. Fleming wrote:
> 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.
Fully ACK.
Regards,
/ismail
On Sun, 2003-06-01 at 10:36, ismail (cartman) donmez wrote:
> On Sunday 01 June 2003 02:37, Kevin P. Fleming wrote:
> > 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.
> >
Well, Redhat do have "sanitized kernel headers", but according to the
whole thread about glibc being broken, it is not the preferred solution.
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.
> > 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.
>
Same here, as the "solution" will not be seen any time soon :/
Regards,
--
Martin Schlemmer
On Monday 02 June 2003 08:43, Martin Schlemmer wrote:
> The solution is to have a set of API headers that userspace can use,
> and that the kernel headers in turn include.
>
Yeah that would be great.
> 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.
>
No glibc,binutils for us then.
Regards,
/ismail