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, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7470 invoked from network); 1 Jan 2023 03:10:20 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2023 03:10:20 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C881941C4C; Sun, 1 Jan 2023 13:10:13 +1000 (AEST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by minnie.tuhs.org (Postfix) with ESMTPS id E0505417A1 for ; Sun, 1 Jan 2023 13:10:08 +1000 (AEST) Received: by mail-ed1-f54.google.com with SMTP id i15so35815461edf.2 for ; Sat, 31 Dec 2022 19:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dpZVJnUHVWwtN9zlnwnhwFEoIi60tHM0TASFLSCK9SE=; b=jxs1TwsTH2qjQyjaeCVi3qozDrnFqXYkn+e0GYTleSDkBeGoEDgtgPt3rIZwnMsCqY 6nQ1C1Yv6RoLHtdrYUdk41slVlt06qqzslpwTMw9Ncbdx31Z2ElbQqW37Obr1BUPyGDE GNEO3oojn41UOgec24yupg9OVVvopVzBOboRvY62ZvR/xomaMqv5u0tgfgQFMl6jV7yy qBWRdcyfu9YyjP/K9jKqvwIvZEa994uu6LViZyy3E2HN74HA6aPE1EFRFX5MvRNin1/W +KtoYTLTVX4BguEPc/pcKfVf3vu1NLPtnnPHUpkTpfF7KFUnCWoY1bSei+7y65l3EPUl B3Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dpZVJnUHVWwtN9zlnwnhwFEoIi60tHM0TASFLSCK9SE=; b=ptfkpfT1gD+IPheRMOgfqW+dEoXOE69DR+VUgilu4CrKi9FrtUmqO/mEt9BEj/tO5K reR1yeeKnPgu98FYzAJpPEeTfPiCpXu8aJ/VeeOshZryuo2ioUNxCjdQeaQm2oQWhr9B gx8N2+xkelUw/92wEw+uM9ZJpYUkwpdQJGFpls624BliTthnrQMMcRLE8QVN7mT30wM8 iWxNz3p/R60V3yZh+7h/ZIMkI4lG+o9bEpuwcEy7oaIBp+tGhL0SLbU+056KhByOBpLr ANZ+guZmaZSbrKCXcGwik1qJ/yGXyvK/YTvwOt5S8KlDDrYBEtAyeTu96ab7IuVUmg/k GMcQ== X-Gm-Message-State: AFqh2kpe42qguuvSyC0QT+U8nr6Cen6qj9sKr25pP+bPsq5ivc5/mzXJ KUXmQSvpJ8dnREO5GYOtGHLNNk1KH4PZMApVvs0XLjWaY8vN+w== X-Google-Smtp-Source: AMrXdXsiJdlcebjRTyNE9Hv2LleR8ZpmDJ+MMa2MMjzw0bG08Uq1XVqSa1a9pFkXyi+awTFgueRgjAJcTeMOi7T24zM= X-Received: by 2002:a05:6402:177c:b0:48c:7e42:8483 with SMTP id da28-20020a056402177c00b0048c7e428483mr230559edb.241.1672542547258; Sat, 31 Dec 2022 19:09:07 -0800 (PST) MIME-Version: 1.0 References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> In-Reply-To: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> From: Warner Losh Date: Sat, 31 Dec 2022 20:08:55 -0700 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="00000000000066c43805f12b28fd" Message-ID-Hash: ASSLVV256DYQL7FCMG7AMQQYR7Y3WXWT X-Message-ID-Hash: ASSLVV256DYQL7FCMG7AMQQYR7Y3WXWT X-MailFrom: wlosh@bsdimp.com 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 CC: The Unix Historical Society 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: --00000000000066c43805f12b28fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal wrote: > > > > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > > > 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 a= lso > appears to be the first appearance of device trees to describe the hardwa= re > to the bios and the kernel. Moreover, it would seem to me that OpenBoot i= s > a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 198= 8 > 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=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. > > > > 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] > Let's not forget that the diversity of systems is 1000s of times greater than it was in the early days of Unix. There were just two busses (Unibus and QBUS) in pdp-11 unix. There were a limited number of peripherals that could live at a limited number of CSRs and compatibility requirements of other DEC OSes meant that most of the 3rd party cards were compatible with DEC gear, though there were exceptions. There was no hot plug, there was no need to hierarchically assign address pools for things like PCIe hot-plug. There was no USB. There were only a very limited number of keyboard and graphics configurations. VAXen increased the number, but not by a huge amount, at least in the early days before new busses were introduced). As such, the unixes from the system III era simply didn't have any notion of this diversity. So trying to layer it in will be quite difficult. The SoC space has become huge, with memory being mapped in different locations, busses being different, etc. There's been much nasty said about FDT and ACPI, but they do solve real problems: how to enumerate this diversity to the OS in a way that's sane and might not always be as simple as returning a specific number but that requires hardware access to answer even basic questions (because, say, the CPUs were wired this way or that and you have to read those wirings). Linux, even in Linuxboot environments, still uses ACPI, FDT and UEFI to get the job done, and the code there isn't horrific. V7 unix for the PDP-11 shipped with maybe 25 drivers total for the whole system, and many of them were quite niche... > 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 th= e > 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. > virtio solves a different problem, though: It's goal is to provide THE interface for mass storage, THE interface for networking, etc so that hypervisor clients can limit their drivers substantially and not have to deal with the thousands of drivers normally needed. ACPI/FDT just try to make the non-self-describing aspects of the hardware described. Which is a different target market (so that one can hook up the right driver of the thousands to choose from when the OS autoconfig's the devices by whatever means it does that, even Linux and System V have this concept, though with radically different code than the BSDs). > 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. > I'd worry that 'use the BIOS' bit here leads to the ugly UEFI/ACPI hybrid to be generic enough to describe everything. Now, I don't disagree with the org chart args for why they are so large outside of linuxboot, but they do fill a vacuum that would otherwise exist. Warner > > [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. > */ > > > > > --00000000000066c43805f12b28fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 31, 2022 at 1:03 PM Paul = Ruizendaal <pnr@planet.nl> wrote= :


> 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, con= fig 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 ha= rdware to the bios and the kernel. Moreover, it would seem to me that OpenB= oot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe b= y 1988 the IO hardware had become sufficiently complex and/or diverse to wa= rrant a break from tradition?
>>
>> Was there any other notable Unix work on better organising the boo= t 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=3D4.1cBSD/a/sys/conf
https://www.tuhs.org/cgi-b= in/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 mor= e
> towards UEFI+ACPI than something like OpenBoot, which was much
> simpler.
>
> In general, the idea of a BIOS isn't terrible: provide an interfac= e
> 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 g= otten 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 kerne= l & host interface
- Devices presented to the OS as virtio devices
- MMU abstraction somewhat similar in idea to that in SYSV/68 [1]

Let's not forget that the diversity of syste= ms is 1000s of times greater than it was in the early days of Unix. There w= ere just two busses (Unibus and QBUS) in pdp-11 unix. There were a limited = number of peripherals that could live at a limited number of CSRs and compa= tibility requirements of other DEC OSes meant that most of the 3rd party ca= rds were compatible with DEC gear, though there were exceptions. There was = no hot plug, there was no need to hierarchically=C2=A0assign address pools = for things like PCIe hot-plug. There was no USB. There were only a very lim= ited number of keyboard and graphics configurations. VAXen increased the nu= mber, but not by a huge amount, at least in the early days before new busse= s were introduced).

As such, the unixes from the s= ystem III era simply didn't have any notion of this diversity. So tryin= g to layer it in will be quite difficult. The SoC space has become huge, wi= th memory being mapped in different locations, busses being different, etc.=

There's been much nasty said about FDT and AC= PI, but they do solve real problems: how to enumerate this diversity to the= OS in a way that's sane and might not always be as simple as returning= a specific number but that requires hardware access to answer even basic q= uestions (because, say, the CPUs were wired this way or that and you have t= o read those wirings). Linux, even in Linuxboot=C2=A0environments, still us= es ACPI, FDT and UEFI to get the job done, and the code there isn't hor= rific.

V7 unix for the PDP-11 shipped with maybe 2= 5 drivers total=C2=A0for the whole system, and many of them were quite nich= e...
=C2=A0
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.

I'd worry that 'use the BIOS' bit here leads to the ugly= UEFI/ACPI hybrid to be generic enough to describe everything.
Now, I don't disagree with the org chart args for why they= are so large outside of linuxboot, but they do fill a vacuum that would ot= herwise exist.

Warner
=C2=A0

[1] From mmu.h in the SYSV/68 source tree:

/*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 @(#)mmu.h=C2=A0 =C2=A0 =C2=A0 =C2=A02.26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the header file for the UNIX V/68 gener= ic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MMU interface. This provides the information th= at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is used by the various routines that call:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmufork ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuexec ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuexit ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuread ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuwrite ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuattach ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmudetach ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuregs ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmualloc ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuinit ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmuint ()

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The above routines and secondary routines calle= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by them are contained in io/mmu1.c and io/mmu2.= c.
*/




--00000000000066c43805f12b28fd--