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

[Dave Dodge]

On Fri, Mar 23, 2007 at 08:49:19PM +0100, Jan-Benedict Glaw wrote:
> 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.

Are there examples of this sort of change happening in the past?

I'm just curious, because my impression was that the system call layer
itself was considered part of the stable user-space API.  If system
calls can suddenly disappear or change their API, then you have some
basic problems:

  - Every kernel update would require a libc update/rebuild.

  - Statically-linked programs would be seriously broken.  Maybe this
    is already the case and I just haven't noticed?

The big problem with the old method of libc copying/massaging headers
was that kernel updates usually happen much faster than libc updates,
and therefore any new system calls or flags would not be visible in
libc's headers even if the kernel supported them.  I think I ran into
this myself a few years ago when an application needed futex support
that was available (backported) in the kernel but not in libc.

                                                  -Dave Dodge