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 9790 invoked from network); 20 Apr 2023 16:04:45 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2023 16:04:45 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 70AB641292; Fri, 21 Apr 2023 02:04:40 +1000 (AEST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by minnie.tuhs.org (Postfix) with ESMTPS id 93D014128E for ; Fri, 21 Apr 2023 02:04:34 +1000 (AEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-506bf4cbecbso971305a12.1 for ; Thu, 20 Apr 2023 09:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682006673; x=1684598673; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cxw8hLAn9QkljNTGOYa95aFDrLtC04qxvXxWsxtoxz8=; b=EB3xIgfNwFghdZqHhBeSkfA90X7WxbhFigwG0bPPwZu92IE2NLQ5aE85UDzGpDqBEz iPHf8glmwXWCU8zlQeS5pdOQptQv86GHDWcJOjx5Opv/XIo2jq6No6OGwe03+WuGrsDQ EGXJFKueD/uO1W0vUNpbSAZqkPj7NnW7hBWMjEu0fg/Vpk6iJQLXod0nhKKidzJoLpGe Cqnqdqo6F9JOXyzn9TykLEls0eqbJKF5oHvmJGs0zwGZgCirlRXwf/PrPl64f4cani7j uNf77Pr+8T6wp0cgBn5CRL7Vd8RlRtgYa933I6t0qjxilAjPUINLGOHEPBxohzkstS1P IvEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682006673; x=1684598673; 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=Cxw8hLAn9QkljNTGOYa95aFDrLtC04qxvXxWsxtoxz8=; b=Nc45cElzHJ8P3O6Jg48eZEyGhbha6TNzUJHQwuOJRJNOQJo2w5mpVLf6EMCqwGZzN8 3Gb+ZkAdUtC7olDlkufiQ6KuEl0K9njuWjPjRLm0xDSvZFi+9kDkccdVMWS20fyu8lX4 CYHNOxjCFiVXhX8A8NaX+fHiaC1044pwj4UMhCi5GmtSpxaytjn59YIYjpqjU/xKZPdI ti4EtxYn1kVYMnODj+muCdIMDu13DVm/hgNsrUcHSc8U2z6pqlnbg8tZp85VYDYh7TZk 3Z3g8yfnBKSWOqoBHlRgN0L+ED24w3mRmPLOUX86ts5psH4xC5YWJTwjaMmxrAWS1swx 3lcA== X-Gm-Message-State: AAQBX9eoQbVjDU3cYzFVzNtxl6EBL7im/Pop4wUHNmCqbmi6hgnzOx8J vk84r7G0P3rSzorygt/GjyCi3niZnYCXCbj43FLMBUClx1ms6nqw X-Google-Smtp-Source: AKy350bvHUYTyXeFvjq5QwOb4pf8Wc7jec1mUl3iFEoXzW0JZ1dI6YCbDWb9IVEWHulC4UwdCcml0LrQJN04GdijE+w= X-Received: by 2002:aa7:c758:0:b0:505:34c:eb38 with SMTP id c24-20020aa7c758000000b00505034ceb38mr2076351eds.11.1682006672726; Thu, 20 Apr 2023 09:04:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 20 Apr 2023 10:04:21 -0600 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="0000000000003cf0da05f9c6b2c3" Message-ID-Hash: 7URV7UXQWNJBU57UNAXH7WWYEXVMRFVK X-Message-ID-Hash: 7URV7UXQWNJBU57UNAXH7WWYEXVMRFVK X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: UNIX "Machine Layer" Standards List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003cf0da05f9c6b2c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 20, 2023 at 8:56=E2=80=AFAM Paul Ruizendaal wro= te: > > > Date: Mon, 10 Apr 2023 18:27:51 +0000 > > From: segaloco > > > ... or was there no single guiding principle and each machine came up, > at that level at least, in a relative vacuum, with only the machine > interface to UNIX being the guiding principle? > > I stumbled into the same question last year, when doing my SysIII to RV64 > port. I managed to turn that into a somewhat chaotic discussion, mixing o= ld > and new, and history with ideas. From that chaotic discussion I got the > impression that it was indeed mostly ad hoc. In context, hardware was muc= h > easier to boot and drive back then -- it probably was not seen as complex > enough to warrant much research into layering and abstraction. > > Also bear in mind that something like a boot rom only became the norm in > the late 70=E2=80=99s. Before that, one keyed in two dozen words with a t= iny > program to load the first boot stage. > > That said, there is an implicit layering in v7 and beyond: > > - =E2=80=9Clow.s" does hardware setup, incl. such stuff as setting up int= errupt > tables. As this is closely tied to the hardware, it would have been a > custom job in each case. > V7 used l.s for this from research, though different names were used in different ports (though many retain l.s too). 32V used locore.s, a convention that all the BSDs I know of picked up and used, as well as many BSD-derived kernels that were later rewritten to support SMP. Oftentimes, the interrupt vector was in the lowest core addresses, and the first part of this file was just a giant table of places to jump for all the different architecturally defined exception and/or vectors (depending on the architecture). Often it contained glue from an interrupt to a ISR call as well, since there were many times where you'd share an exception, get the interrupt "level" or "vector" from some other bit of hardware and this code would often do the simple task of offsetting into a table and jumping. And it also had the "start" entry point for the whole kernel. And frequently silly aux routines like 'doadump' and the bcopy/fubyte(etc)/ and context switching code, which is also in assembler, often ended up there as well. Finally, it was a place to have various bits of storage that the kernel needed to bootstrap whatever VM was there. - =E2=80=9Cmch.s=E2=80=9D (later also mch.c) has the basic routines that ar= e hardware > dependent (switching stacks, changing priority levels and modes, etc.). I= t > also has emulation for =E2=80=98missing=E2=80=99 instructions, such as fl= oating point ops > where this is not available in hardware. Same as above, I think. Maybe h/= w > related memory protection operations should live here as well, but the > hardware was still quite divergent in this area in the 70=E2=80=99s and e= arly 80=E2=80=99s. > 32V called this machdep.c, which all the BSDs inherited. While machine dependent, it tended to be slightly more portable and was for stuff that could be written in C... Agreed on the very divergent part though. > - low-level device drivers live in the =E2=80=98dmr=E2=80=99 or (later) = =E2=80=98io=E2=80=99 directory. > Here there is some standardisation, as all device drivers must conform to > the (char/block) device switch APIs. It seems to me that most of these > drivers were written by taking one that was similar to what needed to be > written and to start from there. Maybe this is still how it works in Linu= x > today. > To be fair, V7 was released in a time where there were no common protocol devices: There was no USB, bluetooth, SATA, SCSI, etc that had divergent drivers to talk to the hardware, but a common transport layer for the protocol. Even MSCP and TSCP, which were the first inklings of this, were a controller interface, not a transport one. The one SCSI driver from this era I've looked at implemented all the SCSI protocol itself. Thankfully the controller had a microcontroller for dealing with the physical signalling bits (unlike a different card for my DEC Rainbow which did it all in hardware by bit-banging I/O ports). > - To the extent that there is such a thing as 'high-level device drivers= =E2=80=99 > in early Unix, the structure is less clearly visible. The file system (an= d > there was only one at the time of v7) is placed between the block device > switch and the mount table so to speak. This was structured enough that > splicing in other file systems seems to have been fairly easy in the earl= y > 80=E2=80=99s (the splicing in, not the writing of the file system itself,= of > course). Starting with 8th edition, the =E2=80=98file system switch=E2=80= =99 created a > clear API for multiple file systems. Arguably, the =E2=80=98tty=E2=80=99 = subsystem is also > a =E2=80=98high-level device driver=E2=80=99, but this one lives as custo= m code together > with the serial port device drivers. Also in 8th Edition, =E2=80=98stream= s' were > introduced. One could think of this as a structured approach to high-leve= l > device drivers for character mode devices, incl. the =E2=80=99tty=E2=80= =99 subsystem. > Yes. It took a long time for there to even be common disk partition handling code. For a long time (and certainly in the V7 ports to PCish boxes) all that was in the driver, and usually cut and pasted from driver to driver. It was only later that better abstraction arose. Network stacks, and the like, were later inventions. > - I don=E2=80=99t think there was ever anything in early Unix that merged > =E2=80=99streams=E2=80=99 and the 'file system switch' into a single abst= raction (but maybe > 9P did?). > I think you're right. They barely had a file system switch... And in the BSD side of the Unix world Network and File system were two different beasts. > Where I'm trying to put this sort of knowledge into use is I'm starting > to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards > (ARM32 and RISCV64 respectively) that is not only sufficient to start a > V7-ish kernel on each, but that are ultimately based on the same design, > varying literally only where the hardware strictly necessitates it, but > similar enough that reading the two assembly files side by side yields > essentially the exact same discrete operations. > > I have a similar interest, but to avoid the same chaos as I created > before, I=E2=80=99ll respond to this with a pm. > I'd be keen to understand this, but it's mostly a passing fancy... Warner --0000000000003cf0da05f9c6b2c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 20, 2023 at 8:56=E2=80=AF= AM Paul Ruizendaal <pnr@planet.nl&g= t; wrote:

> Date: Mon, 10 Apr 2023 18:27:51 +0000
> From: segaloco

> ... or was there no single guiding principle and each machine came up,= at that level at least, in a relative vacuum, with only the machine interf= ace to UNIX being the guiding principle?

I stumbled into the same question last year, when doing my SysIII to RV64 p= ort. I managed to turn that into a somewhat chaotic discussion, mixing old = and new, and history with ideas. From that chaotic discussion I got the imp= ression that it was indeed mostly ad hoc. In context, hardware was much eas= ier to boot and drive back then -- it probably was not seen as complex enou= gh to warrant much research into layering and abstraction.

Also bear in mind that something like a boot rom only became the norm in th= e late 70=E2=80=99s. Before that, one keyed in two dozen words with a tiny = program to load the first boot stage.

That said, there is an implicit layering in v7 and beyond:

- =E2=80=9Clow.s" does hardware setup, incl. such stuff as setting up = interrupt tables. As this is closely tied to the hardware, it would have be= en a custom job in each case.

V7 used l= .s for this from research, though different names were used in different po= rts (though many retain l.s too). 32V used locore.s, a convention that all = the BSDs I know of picked up and used, as well as many BSD-derived kernels = that were later rewritten to support SMP.

Oftentim= es, the interrupt vector was in the lowest core addresses, and the first pa= rt of this file was just a giant table of places to jump for all the differ= ent architecturally defined exception and/or vectors (depending on the arch= itecture). Often it contained glue from an interrupt to a ISR call as well,= since there were many times where you'd share an exception, get the in= terrupt "level" or "vector" from some other bit of hard= ware and this code would often do the simple task of offsetting into a tabl= e and jumping.

And it also had the "start&quo= t; entry point for the whole kernel. And frequently silly aux routines like= 'doadump' and the bcopy/fubyte(etc)/ and context switching code, w= hich is also in assembler, often ended up there as well. Finally, it was a = place to have various bits of storage that the kernel needed to bootstrap w= hatever VM was there.

- =E2=80=9Cmch.s=E2=80=9D (later also mch.c) has the basic routines that ar= e hardware dependent (switching stacks, changing priority levels and modes,= etc.). It also has emulation for =E2=80=98missing=E2=80=99 instructions, s= uch as floating point ops where this is not available in hardware. Same as = above, I think. Maybe h/w related memory protection operations should live = here as well, but the hardware was still quite divergent in this area in th= e 70=E2=80=99s and early 80=E2=80=99s.

= 32V called this machdep.c, which all the BSDs inherited. While machine depe= ndent, it tended to be slightly more portable and was for stuff that could = be written in C...=C2=A0 Agreed on the very divergent part though.
=C2=A0
- low-level device drivers live in the =E2=80=98dmr=E2=80=99 or (later) =E2= =80=98io=E2=80=99 directory. Here there is some standardisation, as all dev= ice drivers must conform to the (char/block) device switch APIs. It seems t= o me that most of these drivers were written by taking one that was similar= to what needed to be written and to start from there. Maybe this is still = how it works in Linux today.

To be fair= , V7 was released in a time where there were no common protocol devices: Th= ere was no USB, bluetooth, SATA, SCSI, etc that had divergent drivers to ta= lk to the hardware, but a common transport layer for the protocol. Even MSC= P and TSCP, which were the first inklings of this, were a controller interf= ace, not a transport one. The one SCSI driver from this era I've looked= at implemented all the SCSI protocol itself. Thankfully the controller had= a microcontroller for dealing with the physical signalling bits (unlike a = different card for my DEC Rainbow which did it all in hardware by bit-bangi= ng I/O ports).
=C2=A0
- To the extent that there is such a thing as 'high-level device driver= s=E2=80=99 in early Unix, the structure is less clearly visible. The file s= ystem (and there was only one at the time of v7) is placed between the bloc= k device switch and the mount table so to speak. This was structured enough= that splicing in other file systems seems to have been fairly easy in the = early 80=E2=80=99s (the splicing in, not the writing of the file system its= elf, of course). Starting with 8th edition, the =E2=80=98file system switch= =E2=80=99 created a clear API for multiple file systems. Arguably, the =E2= =80=98tty=E2=80=99 subsystem is also a =E2=80=98high-level device driver=E2= =80=99, but this one lives as custom code together with the serial port dev= ice drivers. Also in 8th Edition, =E2=80=98streams' were introduced. On= e could think of this as a structured approach to high-level device drivers= for character mode devices, incl. the =E2=80=99tty=E2=80=99 subsystem.
=

Yes. It took a long time for there to even= be common disk partition handling code. For a long time (and certainly in = the V7 ports to PCish boxes) all that was in the driver, and usually cut an= d pasted from driver to driver.=C2=A0 It was only later that better abstrac= tion arose. Network stacks, and the like, were later inventions.
= =C2=A0
- I don=E2=80=99t think there was ever anything in early Unix that merged = =E2=80=99streams=E2=80=99 and the 'file system switch' into a singl= e abstraction (but maybe 9P did?).

I th= ink you're right. They barely had a file system switch... And in the BS= D side of the Unix world Network and File system were two different beasts.=

> Where I'm trying to put this sort of knowledge into use is I'm= starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 b= oards (ARM32 and RISCV64 respectively) that is not only sufficient to start= a V7-ish kernel on each, but that are ultimately based on the same design,= varying literally only where the hardware strictly necessitates it, but si= milar enough that reading the two assembly files side by side yields essent= ially the exact same discrete operations.

I have a similar interest, but to avoid the same chaos as I created before,= I=E2=80=99ll respond to this with a pm.

I'd be keen to understand this, but it's mostly a passing fancy..= .=C2=A0

Warner
--0000000000003cf0da05f9c6b2c3--