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, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6625 invoked from network); 20 Apr 2023 14:56:59 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2023 14:56:59 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id AD6CB41279; Fri, 21 Apr 2023 00:56:54 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 7CD7541261 for ; Fri, 21 Apr 2023 00:56:39 +1000 (AEST) X-KPN-MessageId: 8b719045-df8b-11ed-810d-005056abad63 Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 8b719045-df8b-11ed-810d-005056abad63; Thu, 20 Apr 2023 16:56:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=N+LDvw0SoHdHmp6LJI5XaCLa4QamxzH4pY5C8bIClQ0=; b=iICdA5C4gjDw1lTRlSEfYs5XvZDlruSis9hddDX2l/vgtexXM5jxQyCksBm1Z1JLoTbPuOj4D8bHx htj69tXYOmprT2dzGcVrRIZXLjEG4OnQ3F/JBzvLfRkoJrNgX5gMQXBLQFNSEriSu3Suf7YTF0Vidf kiZBI+vy7VGkykAY= X-KPN-MID: 33|eJQqMpi8I37S2y7A0zn7Xw7mBsK0UXcXV0lO8Ev7qliq07O2HAZuqz+tq5pYuke pLHtj3zybJQ68/nKf3qt2Xb8cgPlx7d12ih5zEf4ySqE= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|UImem8prWsqhVVE8RR+Z7bpBJ+XN8iH76YQsP1kh/iWroOUmE6Xz2YvF4CR96F7 fCUB9FSVYXOl5p8Jxc4IfSA== X-Originating-IP: 77.172.38.96 Received: from smtpclient.apple (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 8b79fcd0-df8b-11ed-b2e8-005056ab7584; Thu, 20 Apr 2023 16:56:35 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: Date: Thu, 20 Apr 2023 16:56:34 +0200 To: "tuhs@tuhs.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: BZPNDDKXLXFBEGBHVG4BHR6TVTA6ZL4P X-Message-ID-Hash: BZPNDDKXLXFBEGBHVG4BHR6TVTA6ZL4P X-MailFrom: pnr@planet.nl 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 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: > 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 old and new, and history with ideas. =46rom that chaotic = discussion I got the impression that it was indeed mostly ad hoc. In = context, hardware was much 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 = 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 = been a custom job in each case. - =E2=80=9Cmch.s=E2=80=9D (later also mch.c) has the basic routines that = are hardware dependent (switching stacks, changing priority levels and = modes, etc.). It also has emulation for =E2=80=98missing=E2=80=99 = instructions, such 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 the 70=E2=80=99s and early 80=E2=80=99s. - 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 Linux today. - 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 (and 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 early 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 custom code together with the serial port device drivers. Also in 8th = Edition, =E2=80=98streams' were introduced. One 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. - 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 abstraction (but maybe 9P did?). > 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.