What's the difference between arch-specific header files of uClib and those header files of linux kernel

Jan-Benedict Glaw jbglaw at lug-owl.de
Fri Mar 23 19:49:19 UTC 2007


On Fri, 2007-03-23 15:26:03 -0400, Rob Landley <rob at landley.net> wrote:
> On Thursday 22 March 2007 10:53 pm, Ahan Hsieh 謝武漢 wrote:
> > Now, I want to port uClibc to a new architecture. 
> > And I have already port uCliunx to this architecture.
> > 
> > When I port uClibc to this new architecture, I got a trouble.
> > 
> > Take fcntl.h as an example:
> > In uClibc/libc/sysdeps/linux/ARCH/bits/fcntl.h of uClibc, 
> > there is also a fcntl.h in linux-2.6.x/include/asm-ARCH/fcntl.h of linux 
> > kernel.
> 
> Back before 2.6.19, Linux didn't have a "make headers_install" target.  The 
> Linux kernel didn't export a clean set of headers that defined its' API with 
> userspace (the ones Linux uses to build itself have all sorts of internal 
> gunk mixed in, and couldn't be used directly without significant cleanup).

It's all quite simple.  Userspace programs interface with the C
library, *not* with the kernel. That is, the C library conforms to
some given standards on the API side (eg. POSIX.1, ANSI, ...), and
an application may use this API.

Most "useful" C libraries, at least those targeting desktop machines,
provide binary compatibility. They offer a stable ABI towards
userland. The result is that you can compile a program in 2007 and
expect it to run even with a libc compiled in 2008.

This implies that a given userspace-visible value *may* *not*
*change*. Ever.  Once you publish eg. O_WRONLY being defined to 1,
you cannot change that value (at least not without breaking userspace,
but it's libc's task to *not* break it!)  Every call to open() is
put into stone to expect 1 for the action of opening a file in
write-only mode.

In contrast to that, the Linux kernel doesn't have a stable ABI. It
doesn't neccessarily even have a stable API. The result is that it's
free to decide to define O_WRONLY to 1 in versions < 2.6.20, and
defining it to 2 for every newer version.  It may even completely drop
the sys_open() syscall and invent a hyper-fcntl like call that,
presented with some magic values, return a file descriptor much like
sys_open() does in current versions.

The C library's task is to keep a stable userspace API (and
hopefully also ABI) and translate that into kernel syscalls (or
emulate it completely), using proper syscalls, defines and structures
that match the *current* kernel.  This leaves a lot of room
for bloat^Wcompatibility, eg. first trying a "new" version
of some syscall (eg. LFS-compliant version), possibly getting a error
of ENOSYS and trying a 32bit version afterwards. Those two different
kernel syscalls may use different sets of flags, and libc will happily
translate its (userspace-visible) flags to proper kernel interface's
flags, which may vary.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
 Signature of:                            If it doesn't work, force it.
 the second  :                   If it breaks, it needed replacing anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20070323/3b06e91e/attachment-0002.pgp 


More information about the uClibc mailing list