Re: Linus's include file strategy redux

[Peter Samuelson <peter@cadcamlab.org>]

[richard offer]
> Or userland libraries/applications that need to bypass libc and make
> direct kernel calls because libc hasn't yet implemented those new
> kernel calls.

Nah, it's still error-prone because it's too hard to guarantee that the
user compiling your program has up-to-date kernel headers in a location
you can find.  Too many things can go wrong.

So just '#include <asm/unistd.h>' -- the libc version -- then have your
own header for those few things you consider "too new to be in libc":

  /* my_unistd.h */
  /* [not sure if all the __{arch}__ defines are right] */
  #include <asm/unistd.h>	/* from libc, not from kernel */
  #ifndef __NR_pivot_root
  # ifdef __alpha__
  #  define __NR_pivot_root 374
  # endif
  # if defined(__i386__) || defined(__s390__) || defined(__superh__)
  #  define __NR_pivot_root 217
  # endif
  # ifdef __mips__
  #  define __NR_pivot_root (__NR_Linux + 216)
  # endif
  # ifdef __hppa__
  #  define __NR_pivot_root (__NR_Linux + 67)
  # endif
  # ifdef __sparc__
  #  define __NR_pivot_root 146
  # endif
  #endif
  #ifndef __NR_pivot_root
  # error Your architecture is not known to support pivot_root(2)
  #endif
  _syscall2(int,pivot_root,char *,new,char *,old)

Yes it's clumsy but it's guaranteed to be where you expect it.  (And
it's not nearly as clumsy if you don't feel the need to support all
architectures.)

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/