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 19913 invoked from network); 31 Dec 2022 20:03:16 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 20:03:16 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 28A1B423D1; Sun, 1 Jan 2023 06:03:04 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (unknown [195.121.94.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 1F933423C0 for ; Sun, 1 Jan 2023 06:02:50 +1000 (AEST) X-KPN-MessageId: 0ba96c81-8946-11ed-8e68-005056ab378f Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 0ba96c81-8946-11ed-8e68-005056ab378f; Sat, 31 Dec 2022 21:02:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=message-id:to:date:subject:mime-version:content-type:from; bh=0GTtm3e45oWy7/PI/XSRK9C/DuuXmIj909WEPyDNtBo=; b=ClplAiQDyu7LYenm4zbE54mgLS6oGUOedpjMP+gzzS3C4/i1GGM7ZUa+sT4vMBqF0vZ+vUJ94rskM ENObiV1WCA8it1iXqmyIMZgkdpjXMpFxSOzqjzNX9EScL2Irk+C/6FBnfur6YjzSNxWg/Xf6llUAs5 kq1iD89a8WQhWdmI= X-KPN-MID: 33|MBALDVHpZSHOjf4KNZJNDJEI167MEqEC/1IlWa8ZB3lcbB7bshLZ9RepLlrfgwI ttYGBJ+z67iDwjAEknb8b5g== X-KPN-VerifiedSender: Yes X-CMASSUN: 33|wmZ//Vk6r4joXS394dvqQzbvLY4PNEO53QLvPvRUyTxCbYjsDvIUoJMHGAEyqpQ 9oruMdbuUAsjdfAeBUEVBhA== X-Originating-IP: 77.172.38.96 Received: from smtpclient.apple (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 139a8426-8946-11ed-927c-005056ab7584; Sat, 31 Dec 2022 21:02:39 +0100 (CET) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sat, 31 Dec 2022 21:02:38 +0100 References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> To: Dan Cross , The Unix Historical Society In-Reply-To: Message-Id: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: OUFIBJ26COFCZFQVU5QZKHY27PWUY5HA X-Message-ID-Hash: OUFIBJ26COFCZFQVU5QZKHY27PWUY5HA X-MailFrom: pnr@planet.nl 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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On 31 Dec 2022, at 15:59, Dan Cross wrote: >=20 > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: >> [snip] >> It would seem that the next step for Unix in the area of boot, config = and device drivers came with Sun=E2=80=99s OpenBoot in 1988 or so. This = also appears to be the first appearance of device trees to describe the = hardware to the bios and the kernel. Moreover, it would seem to me that = OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. = Maybe by 1988 the IO hardware had become sufficiently complex and/or = diverse to warrant a break from tradition? >>=20 >> Was there any other notable Unix work on better organising the boot = process and the device drivers prior to OpenBoot? >=20 > I think that BSD supported autoconfiguration on the VAX well before > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > revamped in 4.4. That is interesting. Are you referring to this: https://www.tuhs.org/cgi-bin/utree.pl?file=3D4.1cBSD/a/sys/conf https://www.tuhs.org/cgi-bin/utree.pl?file=3D4.1cBSD/usr/man/man8/config.8= Or is auto configuration something else? > SBI was/is an attempt to define a common interface to different > devices using RISC-V CPUs, but it's growing wildly and tending more > towards UEFI+ACPI than something like OpenBoot, which was much > simpler. >=20 > In general, the idea of a BIOS isn't terrible: provide an interface > that decouples the OS and hardware. But in practice, no one has come > up with a particularly good set of interfaces yet. Ironically, > BSD-style autoconfig might have been the best yet. When it comes to abstracting devices, it would seem to me that virtio = has gotten quite some traction in the last decade. Looking at both the systems of 40 years ago and the Risc-V SoC=E2=80=99s = of last year, I could imagine something like: - A simple SBI, like the Berkeley Boot Loader (BBL) without the proxy = kernel & host interface - Devices presented to the OS as virtio devices - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] Together this might be a usable Unix BIOS that could have worked in the = early 80=E2=80=99s. One could also think of it as a simple hypervisor = for only one client. The remaining BBL functionality is not all that = different from the content in mch.s on 16-bit Unix (e.g. floating point = emulation for CPU=E2=80=99s that don=E2=80=99t have it in hardware). A = virtio device is not all that different from the interface presented by = e.g. PDP-11 ethernet devices (e.g. DELUA), the MMU abstraction was = contemporary. High end systems could have had device hardware that implemented the = virtio interface directly, low end systems could use simpler hardware = and use the BIOS to present this interface via software. [1] =46rom mmu.h in the SYSV/68 source tree: /* @(#)mmu.h 2.26=20 This is the header file for the UNIX V/68 generic MMU interface. This provides the information that is used by the various routines that call: mmufork () mmuexec () mmuexit () mmuread () mmuwrite () mmuattach () mmudetach () mmuregs () mmualloc () mmuinit () mmuint () The above routines and secondary routines called by them are contained in io/mmu1.c and io/mmu2.c. */