[3182] in Release_Engineering
Ultrix syscall table
daemon@ATHENA.MIT.EDU (Richard Basch)
Sat Apr 16 03:02:25 1994
Date: Sat, 16 Apr 94 03:02 EDT
From: probe@k9.mit.edu (Richard Basch)
To: rel-eng@MIT.EDU
(Sorry, I have a few bounced messages, so I am resending the information
a little out-of-order)
The Ultrix syscall table entry 31 should be changed to afs_syscall, if
AFS is defined.
The older versions of the AFS syscalls (around syscall 192, if I remember)
can be removed safely, since all binaries are now using the later syscalls.
I somehow overlooked the new syscall interface in the kernel, or rather
I confused it with an existing syscall, because the symbolic constants
in the code were AFS_SYSCALL and AFS_AFSCALL (so I read the two to be
the same, and then read one to be a typo, and later figured out that
the two are supposed to be very different).
We have been winning in the past only because 3.2 and prior included
compatibility code such that if the new syscall interface wasn't installed,
it would fall back to using the older interfaces. In 3.3, the compatibility
support was removed, but I have since added it. However, stock Transarc
binaries will not work against our kernels, so we should definitely add
syscall 31, regardless. Basically, if we do, the migration path will be
easier later.
I may or may not be submitting a dkload'able module for the release, but
I'd rather have it such that if anyone compiles a kernel with the AFS
extension built-in, that they not have something incompatible with Transarc
binaries -- I have been trying to move in a direction where there is
compatibility, but it never seems to converge, for one issue or another.
-Richard
