[TUHS] FD 2

[Theodore Ts'o]

On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote:
> 
> Yes, but one legacy of that was Linux tried to use the System V ABI
> everywhere with extensions, and that means errno values are different in
> linux for different platforms, signals are a bit different etc.

Linux used the *Minix* ABI for 32-bit x86, so that Minix 1.x binaries
would run on Linux until recently (when a.out support was removed).
For some of the first original ports (e.g., Alpha and Sparc) there was
an attempt to maintain partial ABI compatibility with OSF/1 and SunOS,
mainly so that proprietary binaries (mostly Netscape) could run on
those Linux ports.  However, for pretty much all of the newer
architectures, the system call and signal numbers used are inherited
from the x86 and x86_64 syscall and signal numbers.  After Netscape
passed, the demand for running non-native binaries rapidly declined.

What you may be remembering was that Linux used to have an emulation
layer for Intel Binary Compatibility Standard (iBCS2)[1].  However,
this was not native support; Linux used "int 0x80" for xx86 system
call with a.out (and later ELF) binaries, while iBCS2 mandated use of
"lcall 7,0" syscalls and COFF binaries.  So iBCS2 support was an
optional thing that you had to explicitly configure the kernel to
support, and while it was quite complete, it was not Linux's native
userspace interface.

[1] https://www.linux.co.cr/free-unix-os/review/acrobat/940612.pdf

Story time: at one point in the early 90's, MIT purchased a site
license for a proprietary spreadsheet product for ISC Unix, which we
planned to run on Linux systems at MIT using iBCS2.  When I contacted
Michael Johnson[2], the engineer at that company to implement support
for the site license ---- which was going to rely on checking the IP
address on the system to see if it was 18.x.y.z --- I found out that
Michael built and tested the spreadsheet using Linux with iBCS2
emulation, and only *later* made sure it would actually run on ISC
Unix, because Linux was a much more pleasant development environment
than the System V alternatives.  :-)

[2] Michael later was one of the founders of Red Hat.

In any case, while in practice some platforms use a unique set of code
points for system calls and signal numbers (thos are mostly the older
architectures which exist mostly for historic interest), most
platforms which run Linux today actually use a consistent set of
system call and signal numbers.

That being said, we did implement many of the System V extensions,
mostly because there was demand from the proprietary software vendors
who needed to be convinced to port their applications from Solars,
HPUX, AIX, etc., to Linux.

Mercifully, Linux never implemented Streams (thank $DEITY Oracle
didn't make that a requirement :-) and we did have BSD job control
from the earliest days.  That happened because in early 1992, I
considered Job Control to be a highly important feature that Linux
**had** to have, and so I sat down with the POSIX.1 specification, and
implemented job control from the spec.  The reason why Linux's tty
layer has a bit of a System V "flavor" at least from a system call
perspective has nothing to do the system call ABI, and more to do with
the fact that apparently representatives from System V derivatives
seemed to have a dominant role on the POSIX committee.

	    	      	     	      	   - Ted