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 27955 invoked from network); 31 Dec 2022 21:05:58 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 21:05:58 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id A612741BEF; Sun, 1 Jan 2023 07:05:52 +1000 (AEST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by minnie.tuhs.org (Postfix) with ESMTPS id 65F3341BC8 for ; Sun, 1 Jan 2023 07:05:47 +1000 (AEST) Received: by mail-ej1-f45.google.com with SMTP id m18so58756036eji.5 for ; Sat, 31 Dec 2022 13:05:47 -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=PdvvBVyW2yeecIExl/ZoiP63CNE2lXQp2gUf45yH0GQ=; b=ifCxfE72P+VmPBuun8dfwMaPCKvCsOXp8/va8F6xLc3rJMkYHIqxz4thnNipID2Tr4 /T9OkF5Hh6Pw18n2r8rNy/RMqw0bywrygZ/ntgeyD1rxFFRRAzlGTGBX1HU4nRyI76W9 J2L/g/+8sGz75uJpqCuFP0MVsbl7pORkhL/nlkOjlFxvNQ83jIdCJuro1bjGL2XrIzcD 4twnOgMYUZkU81Ee9IR0NEHK7UOGAZ2ZIhVmQqtntG0/cul3lp7KIEol1P0f0k7P7g0Y ovWQi6S4z7Ptl9XpsSqp8wzl9XmD8vt9ypFDwG8+b9elecubJcRVv3cCZypoNx2JKvFe YwjA== 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=PdvvBVyW2yeecIExl/ZoiP63CNE2lXQp2gUf45yH0GQ=; b=U7QGkVbv2rj1BHU5iJpnBwS33cgzbctAGD2F5raDt4aO9upSG12OCoV99Poux8JLwi 3wK55LnTsveXguWjG/CarSCTRvY0Cb6QJHfg3cCl9a+Ekki2QK5JmEWiTmGnb/H8vCFY fcNBeE4W6MlV034MJE58gVu+WT9ioYtqsdQXhUC82wJHiF4XKOvUJuC8Qts/zMCPb6g6 ZOb6EF3836NGZX+DbOp1fTtX9+/ek0DtOlPljnL6j+UBpNrpaydHSq6OjwRwbLqpL4dC l6zXNi3ovqXEBlsVWBbFlV+FBQpGLG475qC/m8sdtTUFAqBg43KR+JCwGvYkg4AYsnnt C5nw== X-Gm-Message-State: AFqh2krAaEr1jb1hvq4xXITMNOGkJH0eVNy6nfypKKpDjQRXsqyYbTfr ApiyVvJ49AveAHIkiaeC0rGNPCTjDCfvpokw7jdjGA== X-Google-Smtp-Source: AMrXdXt37F9j7txSd7pX85hHlHPErzie3e/IeQU2y2g3jn77ereHijCOi+Kimas5b1RUiiCiq37vLvwtT1SXdFtXsaw= X-Received: by 2002:a17:906:1858:b0:7c0:e7a6:cd2d with SMTP id w24-20020a170906185800b007c0e7a6cd2dmr2028163eje.317.1672520685709; Sat, 31 Dec 2022 13:04:45 -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 14:04:34 -0700 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="00000000000059fba805f12611db" Message-ID-Hash: ADIRPZCET5GKTYE33ARPXS7W5UCPMSLJ X-Message-ID-Hash: ADIRPZCET5GKTYE33ARPXS7W5UCPMSLJ 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: --00000000000059fba805f12611db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 31, 2022, 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? > OpenBoot also had device drivers written in 4th for OS agnostic goodness. It never caught on, though the concept lives on in AML in ACPI which aims lower in its abstraction... > > > 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? > Config =3D=3D what is in the kernel with some strong hints of where to look= for root and some devices (depending on the busses involved). Autoconf =3D=3D discovering devices during early boot on the system (maybe = with hints from config) and connecting them to the right driver (later with a bidding system for self identifying busses). This process allows GENERIC kernels and for hardware changes. The two are tightly coupled, but happen at different times. Config happens once per build, autoconf happens once per boot (though latter day BSDs will run some subset of this for module loads and device hotplug). Warner > 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] > > 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. > > 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. > */ > > > > > --00000000000059fba805f12611db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


> On 31 Dec 2022, at 15:59, Dan Cross <crossd@gmail.com> wrote:<= br> >
> On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr@planet.nl> w= rote:
>> [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?
<= /div>

OpenBoot also had device= drivers written in 4th for OS agnostic goodness. It never caught on, thoug= h the concept lives on in AML in ACPI which aims lower in its abstraction..= .

>
> 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-b= in/utree.pl?file=3D4.1cBSD/a/sys/conf
https://www.tuh= s.org/cgi-bin/utree.pl?file=3D4.1cBSD/usr/man/man8/config.8

Or is auto configuration something else?

Config =3D=3D what is in the kernel= with some strong hints of where to look for root and some devices (dependi= ng on the busses involved).

Autoconf =3D=3D discovering devices during early boot on the system (ma= ybe with hints from config) and connecting them to the right driver (later = with a bidding system for self identifying busses). This process allows GEN= ERIC kernels and for hardware changes.

The two are tightly coupled, but happen at different times. = Config happens once per build, autoconf happens once per boot (though latte= r day BSDs will run some subset of this for module loads and device hotplug= ).

Warner

> 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]

Together this might be a usable Unix BIOS that could have worked in the ear= ly 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= the 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 dev= ices (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:

/*
=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.
*/




--00000000000059fba805f12611db--