[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tuhs
Subject:    [TUHS] Re: [simh] Announcing the Open SIMH project
From:       Chris Hanson <cmhanson () eschatologist ! net>
Date:       2022-06-07 23:41:06
Message-ID: 931C40D7-F780-454F-B51B-747C713CD31C () eschatologist ! net
[Download RAW message or body]

On Jun 7, 2022, at 10:00 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> Windows and OS X rarely had problems with upward compatibility (newer
> versions able to run executables built for older versions), but Linux
> was living hell. Shared library compatibility was the biggest
> problem. Not only were shared libraries often incompatible between
> different Linux distributions, they were sometimes incompatible even
> between different versions of the same distribution.

That's because, at least when it comes to macOS (nee OS X, nee Mac OS X, nee \
OPENSTEP/Mach, nee NEXTSTEP in various capitalizations) we treat treat binary \
compatibility as something for the operating system as a whole to maintain, not just \
the kernel or the kernel userspace.

Linux's ABI compatibility is itself kind of bare-bones; it achieves userspace \
compatibility by having a fixed set of system call numbers with well-specified \
calling sequences that get compiled into every binary for a particular architecture, \
and it doesn't even attempt to provide the kernel ABI compatibility needed by \
commercial driver vendors.

We handle userspace ABI compatibility in macOS by actually putting the syscalls on \
the other side of a shared library (libSystem.dylib) so the calling sequences and \
syscall numbers are entirely hidden from userspace. We've historically taken a \
different approach to kernel ABI compatibility but have provided it too, though not \
to the same extent as userspace.

As an example of where this helps, things like Linux-derived containers would be much \
faster on non-Linux platforms if the container system could swap in its own \
"libsyscall.so" instead of having to run atop a VM of some sort to handle the Linux \
syscall traps.

  -- Chris


[prev in list] [next in list] [prev in thread] [next in thread]