Re: Inconsistent "#ifdef __KERNEL__" on different architectures

[Albert D. Cahalan]

Paul Mackerras writes:

> The only valid reason for userspace programs to be including kernel
> headers is to get definitions that are part of the kernel API.  (And
> in fact others here will go further and assert that there are *no*
> valid reasons for userspace programs to include kernel headers.)
>
> If you want some atomic functions or whatever for your userspace
> program and the ones in the kernel look like they would be useful,
> then take a copy of the relevant kernel code if you like, but don't
> include the kernel headers directly.

Sure. That copy belongs in /usr/include/asm for all programs
to use, and it should match the libc that will be linked against.
(note: "copy", not a symlink)

Red Hat 7 gets this right:

$ ls -ldog /usr/include/asm /usr/include/linux            
drwxr-xr-x    2 root         2048 Sep 28  2000 /usr/include/asm
drwxr-xr-x   10 root        10240 Sep 28  2000 /usr/include/linux

Debian's "unstable" is correct too:

$ ls -ldog /usr/include/asm /usr/include/linux
drwxr-xr-x    2 root         6144 Mar 12 15:57 /usr/include/asm
drwxr-xr-x   10 root        23552 Mar 12 15:57 /usr/include/linux

> This is why I added #ifdef __KERNEL__ around most of the contents
> of include/asm-ppc/*.h.  It was done deliberately to flush out those
> programs which are depending on kernel headers when they shouldn't.

What, is </usr/src/linux/asm/foo.h> being used? I doubt it.

If /usr/include/asm is a link into /usr/src/linux, then you
have a problem with your Linux distribution. Don't blame the
apps for this problem.

Adding "#ifdef __KERNEL__" causes extra busywork for someone
trying to adapt kernel headers for userspace use. At least do
something easy to rip out. Three lines, all together at the top:

#ifndef __KERNEL__
#error Raw kernel headers may not be compatible with user code.
#endif