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 25336 invoked from network); 30 Dec 2022 18:26:26 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2022 18:26:26 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 83B6842380; Sat, 31 Dec 2022 04:25:49 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168]) by minnie.tuhs.org (Postfix) with ESMTPS id AC3694237E for ; Sat, 31 Dec 2022 04:25:45 +1000 (AEST) X-KPN-MessageId: 30a6132e-886f-11ed-956b-005056aba152 Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 30a6132e-886f-11ed-956b-005056aba152; Fri, 30 Dec 2022 19:24:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=McrjfUcJ3lfJ6T2bkPMUL+8wITbSVVgQ6CbgdF+1AzE=; b=EHuwlDmO33iPbVxMONEcs9qaWmtVY6BT+avKrDWHLEOZAQXmelwV3lTobvbvsFwZE253n5OahAEJy qZDKZVhK2VeG8bTQgR60zkPLOMPeOM+6Vm3lej2/PrS+Q3JKwGZC6CgGQMHtzEZi2r5ew/rtXMldQS UQhj2o1TNqgw2pXk= X-KPN-MID: 33|bLN1FFvLwmCBd2VOhyqpDHxFtlEneJkh1Kjsvmkg0UPY7L2iJ7QHt5pbewhgc1q OorNzd/ijiIKWTNM0cHDCrhKiOcqKR6SyKBCmH6UuEQc= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|BFsRq17kP1vyZLscwKXeSuad/Jy8nA5fxJtoQ68ejQyfJ41I4fSoydQcE6FYlfq ylCOxpqNt+EvqiVaIXPBscw== 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 5f58672a-886f-11ed-927c-005056ab7584; Fri, 30 Dec 2022 19:25:44 +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\)) Message-Id: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Date: Fri, 30 Dec 2022 19:25:43 +0100 To: The Eunuchs Hysterical Society X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: EU6QL2G5DW3HGBBRJJVX4WSQ6DQMD7R5 X-Message-ID-Hash: EU6QL2G5DW3HGBBRJJVX4WSQ6DQMD7R5 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] 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: As mentioned in the first post on SysIII porting, I was surprised to see = how much code was needed to initialise modern hardware and to load an = OS. Of course, modern devices are much more capable than the ones of 40 = years ago, so maybe my surprise is misplaced. It did raise an interest = in the history of Unix system configuration though. It would seem that 5th Edition already contained a configuration program = that generated a few system tables and the =E2=80=98low.s=E2=80=99 file = with interrupt vectors and alike. Although it steadily grew in = sophistication, the approach appears still the same in SysIII. I suppose = this is all in line with common practice of the era, with OS=E2=80=99s = typically having a =E2=80=99system generation kit' to combine the = pre-linked OS kernel with device drivers and system tables. SysIII also introduces the "var struct" and the =E2=80=9Cv=E2=80=9D = kernel variable that summarises some of the system configuration. I=E2=80=99= m not sure whether it has roots in earlier Unix systems, it does not = seem to originate from Research. I=E2=80=99m not sure what the point of = this =E2=80=98v=E2=80=99 kernel variable was. Does anybody remember? One could argue that one of the drivers of the success of CP/M in the = 1970=E2=80=99s was due to its clear separation between the boot rom, = BIOS and BDOS components. As far as I am aware, Unix prior to 1985 did = never attempt to separate the device drivers from the other kernel code. = I am not very familiar with early Xenix, it could be that Microsoft had = both the skill and the interest to separate Xenix in a standard binary = (i.e. BDOS part) and a device driver binary (i.e. BIOS part). Maybe the = differences in MMU for the machines of the early 80=E2=80=99s were such = that a standard binary could not be done anyway and separating out the = device drivers would serve no purpose. Once the PC became dominant, = maybe the point became moot for MS. 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? Was there any other notable Unix work on better organising the boot = process and the device drivers prior to OpenBoot?=20