16 Jul
2021
16 Jul
'21
4:22 a.m.
On Thu, Jul 15, 2021 at 12:49:07PM -0700, Adam Thornton wrote:
Although from a somewhat different perspective,
it's also why the Linux
kernel syscall interface is so unruly, right?
You've got your...some number in the small dozens of common syscalls, which
are already present for the most part in v6 or v7. These are the ones I,
at least, think of when I think of the Unix manual, section 2.
Actually, a more reason why we have so many system calls is that there
is a strong belief that backwards compatibility is important. So much
so that a Linux, or even Minix binary, from the early 1990's, will
still run on a modern Linux kernel today. So that means we have
separate system calls for wait, wait3, wait4, etc. Support for
openat(2), linkat(2), etc., which got added to Posix by way of
Solaris, need to be implemented as a separate system calls, since we
need to keep the original open(2) system calls. Etc.
And obviously there's a tradeoff there. Elegance
departs, and you've
probably introduced some security risk because these syscalls are not
nearly as well-exercised as the common ones, but on the other hand you have
these large companies paying to work on the kernel, and you have them
supporting their product on Linux systems because the system can be bent
into accommodating them more easily, and it will run better there than on
OSes where they don't get to introduce features that benefit their
products, which further drives adoption.
In many cases, inside the kernel, system calls like wait(2) and
wait3(2) will be implemeanted in terms of wait4(2), the implementation
of open(2) and openat(2) share a common codepath, and so on. So
although the *number* of system calls may look big, in many cases
there are shared code paths. This is especially true for the system
calls that implement 64-bit support, where the old legacy 32-bit
system calls are just wrappers that call the 64-bit implementations of
those system calls.
There are also some architectures such as Alpha, where some of Linux's
system calls used the Ultrix system call numbering scheme, and other
Ultrix system calls were emulated, so that the Netscape browser, which
was provided in binary form only for Ultrix on Alpha, would run on
Linux Alpha. Being able to run a subset of Ultrix binaries on Linux
Alpha was certainly a hack, but the ability to run a web browser
(there were no open source web browsers at that time) certainly drove
adoption for at least some users.
Was there perhaps some security risk in doing that? Probably,
although people cared a lot less about that in the early 90's. And
these days Linux support for architectures such as Alpha and HP's
PA-RISC are done only by folks who do for fun. :-)
- Ted
P.S. At one point Linux x86 could also run SCO Unix binaries. Which
led to an amusing situation where MIT had purchased a site license for
a proprietary spreadsheet program that ran on SCO Unix, for use by
students who would be running Linux. I worked with someone at that
company (who eventually became one of the founders of Red Hat) and he
gave me a custom application binary that checked for MIT's IP network
address prefix, which was how the site license enforcement was
implemented.
Turns out his development environment was Linux, cross-compiling to
create a SCO Unix binary, because the Linux development environment
was more developer friendly than SCO's. And so here he was, building
a SCO Unix application on a Linux development machine, and then
handing it to me so that our students could run that SCO Unix
application on Linux systems at MIT. The joys of syscall/OS
emulation. :-)