[TUHS] Re: FD 2

On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote: 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.

34, with not all the errnos defined on all five of these architectures.

[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