From: Paul Ruizendaal <firstname.lastname@example.org>
To: The Eunuchs Hysterical Society <email@example.com>
Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers
Date: Fri, 30 Dec 2022 19:25:43 +0100 [thread overview]
Message-ID: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> (raw)
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 ‘low.s’ 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’s typically having a ’system generation kit' to combine the pre-linked OS kernel with device drivers and system tables.
SysIII also introduces the "var struct" and the “v” kernel variable that summarises some of the system configuration. I’m not sure whether it has roots in earlier Unix systems, it does not seem to originate from Research. I’m not sure what the point of this ‘v’ kernel variable was. Does anybody remember?
One could argue that one of the drivers of the success of CP/M in the 1970’s 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’s 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’s 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?
next reply other threads:[~2022-12-30 18:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 18:25 Paul Ruizendaal [this message]
2022-12-30 18:56 ` [TUHS] " Steve Nickolas
2022-12-31 14:59 ` Dan Cross
2022-12-31 19:08 ` Clem Cole
2022-12-31 21:10 ` Dan Cross
2022-12-31 21:39 ` Clem Cole
2022-12-31 21:52 ` Dan Cross
2022-12-31 23:25 ` Dave Horsfall
2023-01-01 1:02 ` Rob Pike
2023-01-01 1:16 ` George Michaelson
2023-01-01 1:40 ` Larry McVoy
2023-01-01 2:29 ` Warner Losh
2023-01-01 1:24 ` Larry McVoy
2022-12-31 22:38 ` Theodore Ts'o
2022-12-31 22:55 ` Marc Donner
2023-01-01 3:55 ` Dan Cross
2023-01-01 20:29 ` Paul Ruizendaal
2023-01-01 21:26 ` G. Branden Robinson
2023-01-01 21:31 ` Rob Pike
2022-12-31 21:11 ` Paul Ruizendaal
2022-12-31 20:02 ` Paul Ruizendaal
2022-12-31 21:04 ` Warner Losh
2022-12-31 21:41 ` Dan Cross
2023-01-01 3:08 ` Warner Losh
2023-01-01 4:40 ` Dan Cross
2023-01-01 8:05 ` Jonathan Gray
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).