From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19558 invoked from network); 30 Jan 2023 21:02:58 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 21:02:58 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C69774262D; Tue, 31 Jan 2023 07:02:52 +1000 (AEST) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by minnie.tuhs.org (Postfix) with ESMTPS id 2EF3B42611 for ; Tue, 31 Jan 2023 07:02:48 +1000 (AEST) Received: by mail-ej1-f53.google.com with SMTP id kt14so35729141ejc.3 for ; Mon, 30 Jan 2023 13:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aXf8eEbFZp4EpF+WZqjGA3y7tLHL2BKx5XpEtmal3Ng=; b=T7Z5FxKTM7cSruYJhagparRGWEh9XlZoiuKpKyuEQGsVthv/PtN+p4c686k6pfzQdw UJIBNQE2BZqeygf0KDlkuFpX+BtcQ6rCpEs+y5FzVcpKOjkePhsH77Y1jpDRbVy72wYb lHrcg/n5a4gyjJbtg+2l3F/FKecDpE+0wc7IAKoCP6D0QYvdr/hehal1VDYvgnQjfWlA /YHxo/QXDMgat1ZPYiRJyXgPAimU/IzYaiTzkxxAykkP43zcS1Jjq8NrFfCo/IHWJ/Mj zX2twkFmH5l52bjzJMDLdWfCo0HkinSySczxqhxApzjRwc1oQl8+OpPnIXuBcGLhl5I2 5h4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aXf8eEbFZp4EpF+WZqjGA3y7tLHL2BKx5XpEtmal3Ng=; b=NhvEE/aYfTdDYQzrYfva0VEiEzwl2bSMqamsMw8WTEiuBE6QBMnpadHP65p1vkXXHj dR5ibHbsnvO+xITFV+gS/hZU4cLU4EMFcRhUH8PntB5X+6ReD25BOV89dsevWili0INN sH6xZ9/twTATwDec6Rk4TChplv3tty4nxti6kUNfccUT0cNWhWJnBsYBsGcOqgr6jzQk BAKJNs2pg+d8mfIeKX97QtrXJJHur4sCEvQnYBQV5IyCpoHfGGENz8/1eTav/Z67TepA QojjZFImaJpnGznARrMWaj6pUNhBHtfODqfxyBDRXCZ4je520yOhVlhpSsA1Pp++imMR UFrQ== X-Gm-Message-State: AO0yUKW52gCuJue04+98535x/weEFtPQuOzKo0IUbljrnHFo/US2EZ1q gPXjLfYTPxnpai7auke6zMV5PjqcvqLtQ6alR9bZcQ== X-Google-Smtp-Source: AK7set9JL39fCslfFgWM9BVxtGoz0S3ldGqzRqQXmeYZegiWIRbabbSLjxmpxUSeKW6Uz7n2alumXs2Z0A6yBlXgeqY= X-Received: by 2002:a17:906:1653:b0:877:ec3a:ead0 with SMTP id n19-20020a170906165300b00877ec3aead0mr5602090ejd.74.1675112506573; Mon, 30 Jan 2023 13:01:46 -0800 (PST) MIME-Version: 1.0 References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> In-Reply-To: From: Warner Losh Date: Mon, 30 Jan 2023 14:01:35 -0700 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="000000000000e9dbfb05f381853f" Message-ID-Hash: HL3HPWNR2FI2JRZWQWUAFP6XWECNHA47 X-Message-ID-Hash: HL3HPWNR2FI2JRZWQWUAFP6XWECNHA47 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: FD 2 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e9dbfb05f381853f Content-Type: text/plain; charset="UTF-8" On Mon, Jan 30, 2023 at 1:39 PM Theodore Ts'o 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 > --000000000000e9dbfb05f381853f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 30, 2023 at 1:39 PM Theod= ore Ts'o <tytso@mit.edu> wro= te:
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.=C2=A0 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.=C2=A0 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].=C2=A0 However, this was not native support; Linux used "int 0x80" for xx86 syste= m
call with a.out (and later ELF) binaries, while iBCS2 mandated use of
"lcall 7,0" syscalls and COFF binaries.=C2=A0 So iBCS2 support wa= s 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 writte= n a libc-like library for Linux ABI for my kexec the FreeBSD
kern= el=C2=A0 project which produces a Linux binary inside the FreeBSD build
system. I target powerpc64, arm64 and aarch64 (with plans for armv7<= /div>
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 fiv= e of these architectures. There's
also variation in how the d= ifferent 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 thi= s year, using only ELF binaries and trying like heck to
avoid the= oldest, legacy system calls and using only the newer ones that
a= ren'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 ma= ny
special magic things you just have to know to use, and is rath= er Linux centric...
And also the evolved FreeBSD per-arch boot in= terface, which has all those things,
but with somewhat different = details and somewhat FreeBSD centric...

Warner
=C2=A0
[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.=C2=A0 When I contacted<= br> 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.=C2=A0 :-)

[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.=C2=A0 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.=C2=A0 The reason why Linux's tty=
layer has a bit of a System V "flavor" at least from a system cal= l
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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0- Ted
--000000000000e9dbfb05f381853f--