> >From what I can understand, this is all part of the move to 64-bit
> offsets.  About two weeks ago, the old lseek, mmap, truncate and
> ftruncate were renamed to olseek, ommap, otruncate and oftruncate, and
> new 64-bit lseek, mmap, truncate and ftruncate system calls were added
> (I think stat changed too).  This enabled your old applications
> executables to work with the new kernel, and also allow any
> newly-compiled executables to use the new 64-bit calls.  This week,
> the tar_files were made, and then syscalls.h was changed again to move
> the 64bit lseek etc back in place over the old 32-bit lseek etc.  I
> believe old 32-bit off_t calls can be preserved by using "options
> COMPAT_09" in your kernel config file.

That's *not* a correct description of why syscalls.h, etc. were
changed.  Also, it doesn't correctly explain the binary compatibility
issuses here.

Binary compatibility with 0.9, or anything using the original
syscalls, works just fine.

However, as noted in about 3-5 pieces of mail over the last few weeks,
in the process of doing this, the source migrated to a temporary set of
syscalls, because i made a little mistake when first i made the
changes; that's what the messages about 'if you're going to run them,
you must upgrade by XXX' were regarding.

The reason that new binaries were generated *after* the syscall change was:
	(1) i had to upgrade lamp's binaries after the syscalls
		changed
	(2) therefore the binaries could be tested
	(3) i wanted to save people an extra upgrade.


As for the fact that the tar files and binary snapshot was 'out of
sync' -- nobody ever claimed they would be *in* sync, and, if you'll
notice, every time i make a binary snapshot, i note the sources
from which it was made, in the README.  For the last snapshot, that
was "evening, 4/16/94."  I.e. don't try to travel backward in time,
with your sources.


cgd

------------------------------------------------------------------------------