[TUHS] Re: FD 2

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 4919 bytes --]

On Mon, Jan 30, 2023 at 1:39 PM Theodore Ts'o <tytso@mit.edu> wrote:

> 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.
>

So I've written a libc-like library for Linux ABI for my kexec the FreeBSD
kernel  project which produces a Linux binary inside the FreeBSD build
system. I target powerpc64, arm64 and aarch64 (with plans for armv7
maybe and riscv64 for sure). They all have different system call numbers,
slightly different system call encodings and the ERRNOs are different
> 34, with not all the errnos defined on all five of these architectures.
There's
also variation in how the different structures one passes to system calls
are laid out such that I need to have different arch .h files to describe
them (cf stat, dirent, termios). There are generic versions, but even this
small selection of architectures has departures for some or all of them
from the generics.

All of that is from this year, using only ELF binaries and trying like heck
to
avoid the oldest, legacy system calls and using only the newer ones that
aren't crazy to use.

Of course, that's all "chump change" in this project since the evolved kexec
interface on Linux is somewhat different between architectures, involves
many
special magic things you just have to know to use, and is rather Linux
centric...
And also the evolved FreeBSD per-arch boot interface, which has all those
things,
but with somewhat different details and somewhat FreeBSD centric...

Warner


> [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
>

[-- Attachment #2: Type: text/html, Size: 6043 bytes --]