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
Mon Mar 26 19:11:56 UTC 2007


On Mon, 2007-03-26 14:12:54 -0400, Rob Landley <rob at landley.net> wrote:
> On Monday 26 March 2007 1:12 pm, Jan-Benedict Glaw wrote:
> > Read the postings,
> 
> I did.
> 
> > I corrected something.
> 
> What?

That kernel's syscall ABI shouldn't change incompatibly.

> > It doesn't make a difference for 
> > most of the syscalls, but it does for some.  I'm specifically anal for
> > the stat stuff...
> 
> Been there, done that.
> http://uclibc.org/lists/busybox/2004-November/013134.html
> 
> And yet, the binaries that had already been built continued to work just fine.  
> So the _ABI_ was perfectly stable.

I only read that very posting. Isn't it about kernel headers being
used in userspace programs?  That's even another problem, eg. for
stuff like "long" on architectures that have a 32bit as well as a
64bit port?

> There's was a follow-up presentation at this year's linuxconf called "making 
> NFS suck faster", which has video:
> http://www.bestechvideos.com/2007/03/24/linuxconfau-making-nfs-suck-faster/

Is that SGI's talk?  That's quite a nice one even!

> > But there are probably other examples, too.
> 
> A) Hopefully better ones,
> 
> B) Show me one that's intentional breakage rather than a bug.  You're talking 
> about the kernel being (and I quote) "free to decide to define O_WRONLY to 1 
> in versions < 2.6.20".  You're complaining about stat, but if I build stat 
> under Red Hat 5, copy the appropriate binary and shared libraries into a 
> chroot directory on my ubuntu laptop with a 2.6.20 kernel, and run that 
> binary, will it or will it not work?

Erm, I wouldn't require it "intentional breakage". Use of formerly
reserved bits qualifies for me, IFF the libc compiled against earlier
kernel versions doesn't really make sure that reserved stuff is never
ever touched. And please note that I don't specifically talk about
uClibc.

> > That is, I  
> > continue to claim that there are code pathes where a libc should fix
> > up kernel version specific syscall changes.
> 
> Example, please?  (Specific.  No handwaving, show me an actual change to 
> actual code needing to be made, please.)

No specific ones at the hand.

Oh, whee, wait...  Ever tried to run the statically linked SETI at home
client for linux-alpha? Was compiled with an ancient libc and some
linux-specific syscalls were renumbered at some time resulting in
wrong calls being done. Error checking caught it and terminated the
program. That's nothing a statically linked libc could catch, but I
would expect a dynamic version to call the same syscall with different
syscall numbers depending on current kernel's version information.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:            http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second  :
-------------- 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/20070326/6bd78eed/attachment-0002.pgp 


More information about the uClibc mailing list