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

[Rob Landley]

On Monday 26 March 2007 1:12 pm, Jan-Benedict Glaw wrote:
> Read the postings,

I did.

> I corrected something.

What?

> And you're right that Linus  
> and I disagree over one thing. That basically is backward and forward
> compatibility of struct changes.

There is no forwards compatability, only backwards compatability.  Backwards 
compatability says if it ran on 2.4 it should run on 2.6.  Forwards 
compatability says anything that runs on 2.6 it should always run on 2.4, 
I.E. you can never add new features.

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

> So yes, wo do have a mostly stable userland ABI, but we've also seen
> it break. (ISTR some nicely fucked up distcc `make' runs which broke
> due to (non-)availability of subsecond stat() data on a common shared
> filesystem.)

I'm under the impression that NFS servers didn't provide subsecond stat() data 
at all (the kernel was just hallucinating some out of cache) and that running 
make on NFS was a horrible idea from day one.  Also, that trying to get 
accurate timestamp information out of nfs with the way it caches dentries is 
a disaster waiting to happen.

So essentially you're saying that something that was never guaranteed to work 
by anyone, ever, broke for you.  Great.

I saw a marvelous presentation at the last OLS, called "Why NFS Sucks", I 
believe by the current kernel NFS maintainer (I know it's by a guy who has to 
make the linux implementation _work_).  The paper's in the proceedings, or 
broken out here:
http://www-static.cc.gatech.edu/classes/AY2007/cs4210_fall/papers/nfsOLS.pdf

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/

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

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

Rob
-- 
Vista: Windows Millenium Second Edition