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

[Jan-Benedict Glaw]

On Fri, 2007-03-23 15:16:59 -0500, Dave Dodge <dododge at dododge.net> wrote:
> 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?

Yes, even quite some prominent ones. For example, the stat() functions
have a quite static userland representation, but their kernel
equivalent is different.  That even changed (when nanosecond
resolution was made ready.)

Think even further: There might be more than _one_ userland ABI, like
running 64bit _and_ 32bit code on a ia64/x86_64 box.

> 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.

A syscall doesn't change. (At lease, it doesn't change in an ABI
breaking fashion...)  syscalls are only added, never removed. (Well,
only if you redesign the whole stuff, which you may do *once*, after
you finished the libc port and realize that you kept some old-style
syscalls instead of using their newer versions. Eg. we're considering
doing that for vax-linux when there's GNU libc port.)

So it only requires a libc rebuild if you want to take advantage of
new features.

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

Due to the syscalls-aren't-ever-removed and syscalls-don't-change
constraints, static programs should just work.

> 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.

:-)  This is where the private fun of local helper libraries, own
header files and _syscallX begins!

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:                     Eine Freie Meinung in einem Freien Kopf
the second  :                   für einen Freien Staat voll Freier Bürger.
-------------- 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/ff34cbdf/attachment-0002.pgp