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, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15597 invoked from network); 30 Jan 2023 20:39:24 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 20:39:24 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 8A0CD4263F; Tue, 31 Jan 2023 06:39:18 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 3579A4263E for ; Tue, 31 Jan 2023 06:39:13 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 30UKd0PT018835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2023 15:39:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1675111141; bh=nVwpXbEHnAbhwYTTtxw9FuRsStPEZBU1YEkByFNj6Fg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ATM0rfcN1e715L/yt2GzwpK3QdfaKoDQpfJtRJU3hHCpXPkDkYPy3UL0g5iNzmBwz VE2DmlqXzA5apgokia4eDWO7TWOw61/BRhaWAkq4iR60MQI+Cb5BCTZiKK9l06x0gE nSuwFY2gjOGm5RhHTTrGwCK6D9cZvJXq7mqUrFQqQkWr3bE0gSjvADBwxBrFQVZb1O 5r7UmKDu+iU9hUs4/jBWBQl5hcGV+bn3qgJipkBdczNpof6Ogv1VhvzjXaVgaHwVjF E05FHsw7igRN+fDWcLT4JcNy2+/PZDYbxPE4MrF79E8NqahhDykJDXk8bJ1KlSugnt fuLfRUKneeMnA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id DE8FE15C359D; Mon, 30 Jan 2023 15:38:59 -0500 (EST) Date: Mon, 30 Jan 2023 15:38:59 -0500 From: "Theodore Ts'o" To: Warner Losh Message-ID: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: QSYIHNJMVO4U6K7HVEUOWUACNXAFLZJH X-Message-ID-Hash: QSYIHNJMVO4U6K7HVEUOWUACNXAFLZJH X-MailFrom: tytso@mit.edu 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: 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