syscall(2)
Richard O'Keefe
ok at cs.mu.oz.au
Fri Oct 20 23:05:09 AEST 1989
There is a certain programming language interpreter which I would like to
try out on an ELXSI system. The implementors of this particular program
decided to rely fairly seriously on syscall(2). For example, when you as
the interpreter to load a source file, it first executes some interpreted
code to check if the file is available, and that calls access(2) through
an interpreted call to `syscall'. Please don't flame *me*, I do know
better than to use access(2) for such purposes, and if I was that ignorant
I'm still not crazy enough to do it through syscall(2).
The problem is that although the ELXSI announces itself as "ELXSI 4.3 BSD UNIX"
it does not appear to provide 'syscall' in the usual C library. There is a
<syscall.h> header which defines the system call numbers, but no syscall()
function is apparent.
The Encore Multimax (System V) doesn't seem to have heard of syscall(2)
at all, yet the program came with patches for a fourth machine which
also runs System V, and the patches appear to show that that machine has
got syscall(2).
Q1: Did syscall() survive from V6 into System V, or is it as big a
portability problem as it looks?
Q2: Are systems which advertise themselves as "4.3BSD" likely to use the
same syscall numbers for things which are part of 4.3BSD? (It was
not a surprise to me that the ELXSI does not support SYS_vpixsys.)
(Yes, I _know_, putting the numbers into your code is like lying down on
the tram lines and just _begging_ Fate to kick you in the teeth. I did
_not_ write this program myself.)
Short term, I'd like to get the thing going on the ELXSI.
Long term, I'd like some evidence that I can send to the original author
which _might_ persuade him that building syscall numbers into the code is
not a good idea.
More information about the Comp.unix.questions
mailing list