The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: Dan Cross <crossd@gmail.com>,
	The Unix Historical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers
Date: Sat, 31 Dec 2022 21:02:38 +0100	[thread overview]
Message-ID: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> (raw)
In-Reply-To: <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>



> On 31 Dec 2022, at 15:59, Dan Cross <crossd@gmail.com> wrote:
> 
> On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr@planet.nl> wrote:
>> [snip]
>> 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?
> 
> 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=4.1cBSD/a/sys/conf
https://www.tuhs.org/cgi-bin/utree.pl?file=4.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.
> 
> 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’s 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’s. 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’s that don’t 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] From mmu.h in the SYSV/68 source tree:

/*
	@(#)mmu.h	2.26 
	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.
*/





  parent reply	other threads:[~2022-12-31 20:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 18:25 [TUHS] " Paul Ruizendaal
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 [this message]
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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl \
    --to=pnr@planet.nl \
    --cc=crossd@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).