The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Dan Cross <crossd@gmail.com>
Cc: Paul Ruizendaal <pnr@planet.nl>,
	The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers
Date: Sat, 31 Dec 2022 14:08:10 -0500	[thread overview]
Message-ID: <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com> (raw)
In-Reply-To: <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

On Sat, Dec 31, 2022 at 10:02 AM Dan Cross <crossd@gmail.com> wrote:

> 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.
>
I can verify that.   The PDP-10's had it first, then VMS.  During the VMS
vs UNIX war at ARPA, when Joy did the FASTVAX work, autoconfig
 first appeared.   Sam rewrote it with what eventually became 4.2 with his
configuration system.

At the point of the vendors like, DEC, DG, HP, then Masscomp, Apollo and
Sun all had their own boot systems.  For Vaxen that was ok, as the busses
were DEC defined, but folks like Xylogics, Emulex and such wanted to sell
boards for the Multibus, VME as well as Unibus or proprietary busses.   So
boot driver were something they had to offer in source, at least to their
OEM's [actually Masscomp (Paul Cantrell) wrote Xylogic's reference code for
a number of them and licenses them back, which Sun used later as it turns
out].

Larry and Rob G can comment on the OpenBoot stuff what was birthed later on
as a way to solve some of that problem.  IIRC, the SPARC may have been a
partial driver for that as offering boot rooms and driver for 68000 or 8086
based boards was not going to be helpful for that market.

>
> 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.
>
UEFI+ACPI got/gets a bad rep because of the original IBM BIOS
implementations.

>
> In general, the idea of a BIOS isn't terrible: provide an interface
> that decouples the OS and hardware.

Exactly - the idea is actually a good one.  But the problem was the BIOS
designed/implemented by HW people, but OS folks.  Things like concurrency
minimum use of the CPU was not in the higher order bits.



> 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.
>
??Maybe because it was OS types who knew what the OS needed to
discover/report/deliver back from the HW.

[-- Attachment #2: Type: text/html, Size: 4177 bytes --]

  reply	other threads:[~2022-12-31 19:10 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 [this message]
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

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=CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=crossd@gmail.com \
    --cc=pnr@planet.nl \
    --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).