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 3:11 pm, Jan-Benedict Glaw wrote:
> 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.  It never did except via bugs that got fixed.  How does this 
qualify as you correcting anything or anyone?

Who did you correct?  Perhaps Linus, who spent two messages telling you that 
the kernel has no static internal ABI but (and I quote, in his very first 
message to you):

> People care _deeply_ about the user-visible Linux ABI - I personally think
> backwards compatibility is absolutely _the_ most important issue for any
> kernel, and breaking user-land ABI's is simply not done.

How does that qualify as you "correcting" anybody?  Linus corrected you at 
great length by pointing out the difference between the user-land ABI 
(stable) and the in-kernel ABI (outright ephemeral), which you're STILL 
conflating.  The kernel headers at the start of this define the 
kernel-to-userspace ABI.

(By the way, as a side note, if it _did_ change then we'd obviously want to 
feed the kernel what it expected or it wouldn't WORK, so even in the case of 
your "it doesn't happen" example, the course of action I suggested (use the 
kernel ones) would be correct.  Even imaging for a moment that your entire 
argument WASN'T based on an incorrect assumption, you'd still be wrong about 
the correct course of action.  This isn't RELEVANT because it doesn't happen, 
but it just goes to show that you've got _layers_ of wrong in here.)

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

I'm not going to read the thread to you.  The tip of the iceberg was me 
pointing out that I've dealt with changes in kernel header versions before, 
and I'm drawing on experience when I say you're spreading FUD.

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

The first one was Olaf's.  He works at SGI.  That's not quite the same thing 
as it being an SGI talk.  The video I haven't watched yet, it's on my todo 
heap.

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

Did you honestly not understand that I was asking for an example of a new 
kernel intentionally breaking existing userspace programs?  Is there some 
kind of language problem, perhaps?

> Use of formerly 
> reserved bits qualifies for me,

They were reserved for a reason.  Setting them could do anything.  This is why 
they're reserved.  They're not "should always be zero", they were "new 
functionality could be added to these in future".

So yes, explicitly, adding new features equates to ABI breakage by your 
definition, and your definition is not only useless but conflicts with most 
major standards bodies.

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

Initializing reserved bits to zero is generally part of compliance with a 
given spec.  It's possible to have a buggy libc, although the way modern C 
compilers works you'd have to go out of your way to do it.

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

I repeat my earlier statement: you are trolling.  I've asked you to show me 
how you aren't, and you can't.  I've shown this previous thread responded to 
(contradicting you) by the highest authority available on the topic, Linus 
Torvalds himself, and you've continued to assert the position he contradicted 
without being able to back it up with anything but handwaving.

After this message, I'm going to stop feeding the troll.

> Oh, whee, wait...  Ever tried to run the statically linked SETI at home
> client for linux-alpha?

The last time I had an alpha working in my presence was 1998, at which time 
SETI at home didn't exist.  The uClibc ALPHA build has been broken in the 
nightly builds as long as I can remember, because nobody's bothered to fix 
it.

No, I haven't.

> Was compiled with an ancient libc and some 
> linux-specific syscalls were renumbered at some time resulting in
> wrong calls being done.

So, on a hardware platform that for most purposes no longer exists, using some 
libc you can't remember, using some syscalls you can't be specific about, and 
you don't even METION a kernel version, you once encountered a bug.  You 
don't know what the actual bug was, but are sure it supports your position.

Great.

As evidence to overcome the explicit, stated policy of the Linux kernel 
developers themselves, which Linus Torvalds enunciated directly to you in a 
public kernel thread I pulled out of the archives, I must say how deeply and 
profoundly compelling this isn't.

> Error checking caught it and terminated the 
> program.

Ok, I'm presuming that you replaced the kernel and nothing else, when this 
program stopped working.  So it wasn't that you had a different filesystem 
with different paths or different file permissions or different user ID or a 
different IP address or anything that could actually affect the running of 
the program.

That fact you mention the application as statically linked sort of implies 
that you DID take it to a different filesystem, which could have all sorts of 
things different in it unrelated to the kernel.  If you didn't do this, then 
it wouldn't really matter if it was statically linked or not, no?

But giving you the benefit of the doubt for a moment, and before we get to the 
kernel, let's look at what statically linking doesn't do.  With glibc it 
doesn't suck in the libnss files, so any attempt to do a dns lookup (which 
seti at home might very well do) is going to fail, and it can also screw up 
logins and attempts to look up user information, depending on how things are 
configured.  And this is assuming that seti at home doesn't dlopen any of its 
_own_ libraries, which you didn't copy to the new system.

Now let's look at the kernel.  #1: did your new kernel have a slightly 
different configuration than the previous one?  #2: did this new kernel have 
a bug that was fixed in future versions?  I can come up with more questions, 
but this is starting to sound like a "cupholder" tech support call.

You once hit a bug.  You can't be remotely specific about it, and admit you 
don't know what it actually was, but obviously it proves your point.  Right.

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

What you would expect and what reality are has been shown to diverge on 
multiple occasions.  You have no evidence whatsoever for the above statement, 
your analysis has a "this guy once said" level of detail, and have carefully 
placed it into a context in which it can't POSSIBLY be reproduced.

You are a troll.  I'm going to stop feeding you now.

Rob
-- 
Vista: Windows Millenium Second Edition