From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux 0.97p2 compatibility, GCC/SHAREDLIBS/JUMPTABLES.
Date: 6 Sep 92 18:55:49 GMT
Organization: University of Helsinki

In article <BALASUB.92Sep6121304@organ.cis.ohio-state.edu> balasub@organ.cis.ohio-state.edu (Krishna Balasubramanian) writes:
>
>GCC main releases, the corresponding linux version and some
>distributions that use this version of GCC are  approximately 
>as follows: (see the GCC FAQ to find out more).
>
>1) 2.11c, May 19        linux 0.96       x11v1.0 
>2) 2.2.2, Jun 27      > linux 0.96ap4    rootdisk-0.97, x11v1.1, SLS, MCC-0.96c.
>3) 2.2.2d Aug 12      > linux 0.97p1     rootdisk-0.97.1 , MCC-0.97p2
>
>There will probably be a new GCC version with X11 in a week or so.

Right.  And in case anybody is nervous about the inverse relation (ie
running old programs under new kernel releases), that should always work
*barring bugs or "undocumented features"*.  So all old binaries will
generally work on new versions of the kernel. 

The ptrace() interface was changed in 0.95 - but that was before gdb was
publically available, and it broke no binaries.

Other than things like that, all "nice" programs should work from one
release to another.  They may not be able to use new features (VFS etc),
but they should work as well as they ever did.  Note that new gcc
versions, new features etc have made a recompile a good idea, but not
strictly necessary - I still use the following programs:

 -rwxr-xr-x   1 torvalds uucp         9491 Aug 19  1991 /bin/sync
 -rwxr-xr-x   1 torvalds uucp        20640 Aug 21  1991 /usr/bin/dhrystone
 -rwxr-xr-x   1 torvalds uucp        72091 Sep  8  1991 /usr/bin/egrep
 -rwxr-xr-x   1 torvalds uucp        72090 Sep  8  1991 /usr/bin/grep
 -rwxr-xr-x   1 torvalds uucp        31176 Sep 13  1991 /usr/bin/od

and they work perfectly ok even though some of them are probably from
before the 0.01 release.

"non-nice" programs include the 'ps'-suite of programs that muck around
with kernel memory, and simply buggy programs that may work on older
releases. An example of the latter is anything that accesses memory that
it hasn't first allocated with 'brk()'. Those programs worked fine in
0.96, but 0.96b (I think) adopted the standard unix practice of sending
such a program a SIGSEGV.

Similarly, some 'mount' binaries won't work under 0.97.pl2 even though
they worked on pl1.  They did a no-no that just happened to go unchecked
in the older kernel.  Another example of a program that didn't work with
pl2 was "lilo" - it depended on the stat() system call returning the
same buffer-size as used internally in the kernel, which no longer is
necessarily true (and just happened to work in earlier versions). 

Of course, there are also kernel bugs that can result in a binary not
working under a new release: this happened in pl2 with the symlink code
and to a lesser extent with /dev/mem.  I generally try to fix that kind
of thing as fast as possible: pl3 has these corrected. 

So if you are using an old kernel in the fear that things won't work
with a newer version, you should probably at least try to upgrade: the
chances are everything works fine even if you don't have the latest
user-level binaries.  On the other hand, it may be only prudent to wait
a while until a release has shown itself to be stable - people who are
happy with their current kernel don't necessarily need to upgrade (but
don't be surprised if some new binary doesn't work). 

		Linus

PS.  None of the above means that future versions of linux will
necessarily be 100% compatible.  If I decide it's worth it, I might
break all old programs by doing something in a more clever way.  But
I'll document it very clearly if I'm aware of the problem.  And it's not
very likely: after all I'm running the same programs as everybody else
(and older versions than some), and I don't feel any terrible urges to
recompile everything. 
Newsgroups: comp.os.linux