From tuhs at tuhs.org Sat Apr 1 04:13:38 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 31 Mar 2023 18:13:38 +0000 Subject: [TUHS] Paper Scan of Research V4 Manual? Message-ID: Good afternoon, folks. I was wondering if anyone is aware of/possesses a scanned copy (or paper copy ripe for scanning) of the research V4 UNIX Programmer's Manual. I've found a few rendered PDFs from the available manpage sources, but I am looking to do some comparison of original typesetting re: my restorations of various other sets of manpages. I have scans of all the other research versions I believe, just not V4. Thanks in advance! - Matt G. From ron at ronnatalie.com Sun Apr 2 02:34:17 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 01 Apr 2023 16:34:17 +0000 Subject: [TUHS] Warning: April Fools Message-ID: Once again, I must dredge up this post from 1991…. >From spaf at cs.purdue.EDU Thu Apr 4 23:11:22 1991 Path: ai-lab!mintaka!mit-eddie!wuarchive!usc!apple!amdahl!walldrug!moscvax!perdue!spaf From: spaf at cs.purdue.EDU (Gene Spafford) Newsgroups: news.announce.important,news.admin Subject: Warning: April Fools Time again (forged messages on the loose!) Message-ID: < 4-1-1991 at medusa.cs.purdue.edu> Date: 1 Apr 91 00:00:00 GMT Expires: 1 May 91 00:00:00 GMT Followup-To: news.admin Organization: Dept. of Computer Sciences, Purdue Univ. Lines: 25 Approved: spaf at cs.purdue.EDU Xref: ai-lab news.announce.important:19 news.admin:8235 Warning: April 1 is rapidly approaching, and with it comes a USENET tradition. On April Fools day comes a series of forged, tongue-in-cheek messages, either from non-existent sites or using the name of a Well Known USENET person. In general, these messages are harmless and meant as a joke, and people who respond to these messages without thinking, either by flaming or otherwise responding, generally end up looking rather silly when the forgery is exposed. So, for the few weeks, if you see a message that seems completely out of line or is otherwise unusual, think twice before posting a followup or responding to it; it's very likely a forgery. There are a few ways of checking to see if a message is a forgery. These aren't foolproof, but since most forgery posters want people to figure it out, they will allow you to track down the vast majority of forgeries: o Russian computers. For historic reasons most forged messages have as part of their Path: a non-existent (we think!) russian computer, either kremvax or moscvax. Other possibilities are nsacyber or wobegon. Please note, however, that walldrug is a real site and isn't a forgery. o Posted dates. Almost invariably, the date of the posting is forged to be April 1. o Funky Message-ID. Subtle hints are often lodged into the Message-Id, as that field is more or less an unparsed text string and can contain random information. Common values include pi, the phone number of the red phone in the white house, and the name of the forger's parrot. o subtle mispellings. Look for subtle misspellings of the host names in the Path: field when a message is forged in the name of a Big Name USENET person. This is done so that the person being forged actually gets a chance to see the message and wonder when he actually posted it. Forged messages, of course, are not to be condoned. But they happen, and it's important for people on the net not to over-react. They happen at this time every year, and the forger generally gets their kick from watching the novice users take the posting seriously and try to flame their tails off. If we can keep a level head and not react to these postings, they'll taper off rather quickly and we can return to the normal state of affairs: chaos. Thanks for your support. Gene Spafford, Net.God (and probably tired of seeing this message) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Apr 2 03:55:15 2023 From: cowan at ccil.org (John Cowan) Date: Sat, 1 Apr 2023 13:55:15 -0400 Subject: [TUHS] Warning: April Fools In-Reply-To: References: Message-ID: See also . Yesterday, indeed, I got an obviously misdirected email on my work account, I clicked on a link in it to try to figure out what had gone wrong, and found myself on a page informing me that $EMPLOYER had just phished me, and I was being sent to a re-education camp (well, in fact I just had to look at some slides and answer questions). Of course, it's very difficult to train people out of being careless and impulsive. -- John Cowan {backbones}!rutgers!hombre!magpie!cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sun Apr 2 10:08:24 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 2 Apr 2023 10:08:24 +1000 Subject: [TUHS] Warning: April Fools In-Reply-To: References: Message-ID: <73FC4C4C-7479-4747-A528-3A49BB62752C@canb.auug.org.au> [ Please post follow-ups to COFF ] Ron, Thanks for the history, enjoyed very much. Quite relevant to Early Unix, intertwined with VAxen, IP stack from UCB, NSF-net & fakery. The earliest documented Trojan, Unix or not, would be Ken’s login/cc hack in his “Reflections on Trust” paper. It was 1986 when Clifford Stoll tracked a KGB recruit who broke into MILNET, then the first “honeynet” by Stoll. 1986 was also the first known PC virus according to Kaspersky. The SANS Institute was formed the next year, 1989, creating structured training & security materials. This structured, co-ordinated response, led by technical folk, not NatSec/ Intelligence/ Criminal investigation bodies, created CVE’s, Common Vulnerabilities and Exposures, as a way to identify & name unique attacks & vectors, track them and make vendors aware, forcing publicity & responses. The Internet eventually became a significant theatre of Crime & Espionage, Commercial & National Security. Mandiant was formed in 2004 to identify, track and find sources of APT’s, Advanced Persistent Threats. In 2010, they described APT’s tracked in their “M-trends” newsletter. in Feb 2013, Mandiant publicly described “APT1” and the military unit & location they believed ran it. ============= > On 2 Apr 2023, at 02:34, Ron Natalie wrote: > > Once again, I must dredge up this post from 1991…. ============= For future reference, Kremvax lives! [ datestamp in email header ] iMac1:steve$ host kremvax.demos.su kremvax.demos.su has address 194.87.0.20 kremvax.demos.su mail is handled by 100 relay2.demos.su. kremvax.demos.su mail is handled by 50 relay1.demos.su. iMac1:steve$ ping -c2 kremvax.demos.su PING kremvax.demos.su (194.87.0.20): 56 data bytes 64 bytes from 194.87.0.20: icmp_seq=0 ttl=46 time=336.127 ms 64 bytes from 194.87.0.20: icmp_seq=1 ttl=46 time=335.823 ms --- kremvax.demos.su ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 335.823/335.975/336.127/0.152 ms ============= -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From noel.hunt at gmail.com Sun Apr 2 17:39:32 2023 From: noel.hunt at gmail.com (Noel Hunt) Date: Sun, 2 Apr 2023 17:39:32 +1000 Subject: [TUHS] Warning: April Fools In-Reply-To: References: Message-ID: Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. A translation would be most helpful. It looks like a mixture of Spanish and Mediaevel French...ah, it is the La Chanson de Roland. On Sun, 2 Apr 2023 at 03:55, John Cowan wrote: > See also . > > Yesterday, indeed, I got an obviously misdirected email on my work > account, I clicked on a link in it to try to figure out what had gone > wrong, and found myself on a page informing me that $EMPLOYER had just > phished me, and I was being sent to a re-education camp (well, in fact I > just had to look at some slides and answer questions). Of course, it's > very difficult to train people out of being careless and impulsive. > > -- > > John Cowan {backbones}!rutgers!hombre!magpie!cowan > Charles li reis, nostre emperesdre magnes, > Set anz totz pleinz ad ested in Espagnes. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Sun Apr 2 21:18:12 2023 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 2 Apr 2023 23:18:12 +1200 Subject: [TUHS] Warning: April Fools In-Reply-To: References: Message-ID: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> "Charles the King, our great emperor" (and the rest I can only guess at. It's referring to King Chuck the Great, Karl der Gross, Charlemagne. Or if you like, the Great and Magnificent King Upchuck. :) ) It's not Spanish; I thought it had a touch of Occitan/Catalan, but I could be wrong. Wesley Parish On 2/04/23 19:39, Noel Hunt wrote: > Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad > ested in Espagnes. > A translation would be most helpful. It looks like a mixture > of Spanish and Mediaevel French...ah, it is the La Chanson de > Roland. > > On Sun, 2 Apr 2023 at 03:55, John Cowan wrote: > > See also . > > Yesterday, indeed, I got an obviously misdirected email on my work > account, I clicked on a link in it to try to figure out what had > gone wrong, and found myself on a page informing me that $EMPLOYER > had just phished me, and I was being sent to a re-education camp > (well, in fact I just had to look at some slides and answer > questions). Of course, it's very difficult to train people out of > being careless and impulsive. > > -- > > John Cowan {backbones}!rutgers!hombre!magpie!cowan > Charles li reis, nostre emperesdre magnes, > Set anz totz pleinz ad ested in Espagnes. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Sun Apr 2 22:29:03 2023 From: meillo at marmaro.de (markus schnalke) Date: Sun, 02 Apr 2023 14:29:03 +0200 Subject: [TUHS] Warning: April Fools In-Reply-To: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> References: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> Message-ID: <1piwpT-8E5-00@marmaro.de> Hoi, As Noel already mentioned, it's from the Song of Roland. See here, the beginning of this old french version: https://fr.wikisource.org/wiki/La_Chanson_de_Roland/L%C3%A9on_Gautier/%C3%89dition_critique/Premi%C3%A8re_partie meillo [2023-04-02 23:18] Wesley Parish > > "Charles the King, our great emperor" > > (and the rest I can only guess at. It's referring to King Chuck the Great, Karl > der Gross, Charlemagne. Or if you like, the Great and Magnificent King Upchuck. > :) ) It's not Spanish; I thought it had a touch of Occitan/Catalan, but I could > be wrong. > > Wesley Parish > > On 2/04/23 19:39, Noel Hunt wrote: > > Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in > Espagnes. > A translation would be most helpful. It looks like a mixture > of Spanish and Mediaevel French...ah, it is the La Chanson de > Roland. > > On Sun, 2 Apr 2023 at 03:55, John Cowan wrote: > > See also . > > Yesterday, indeed, I got an obviously misdirected email on my work > account, I clicked on a link in it to try to figure out what had gone > wrong, and found myself on a page informing me that $EMPLOYER had just > phished me, and I was being sent to a re-education camp (well, in fact > I just had to look at some slides and answer questions).  Of course, > it's very difficult to train people out of being careless and > impulsive. > > --  > > John Cowan {backbones}!rutgers!hombre!magpie!cowan > Charles li reis, nostre emperesdre magnes, > Set anz totz pleinz ad ested in Espagnes. > > > From skogtun at gmail.com Sun Apr 2 23:46:20 2023 From: skogtun at gmail.com (Harald Arnesen) Date: Sun, 2 Apr 2023 15:46:20 +0200 Subject: [TUHS] Warning: April Fools In-Reply-To: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> References: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> Message-ID: <2f3bf40b-af75-f899-58a1-611b8c52a8c7@gmail.com> Wesley Parish [02/04/2023 13.18]: > It's referring to King Chuck the Great, Karl der Gross, Charlemagne. Or > if you like, the Great and Magnificent King Upchuck. :) ) Karlamagnus, as the vikings called him. -- Hilsen Harald Слава Україні! From tuhs at tuhs.org Mon Apr 3 15:03:56 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 03 Apr 2023 05:03:56 +0000 Subject: [TUHS] Manpage Analysis Repository (And V1/V2 roff Restorations) Message-ID: Good evening or whatever time of day you find yourself in. I've just finished the first tag in a git repository I've put together to track UNIX developments as documented in the manual. In preparation for this, I also created restorations of the V1 and V2 manuals in roff based on the available V3 sources. The repositories for all this can be found here: https://gitlab.com/segaloco/mandiff https://gitlab.com/segaloco/v1man https://gitlab.com/segaloco/v2man There are most certainly typos and minor discrepancies still to be found between sources and the PDF scans, but given all the cross-referencing involved I believe the manual restorations to be largely complete. As for the mandiff repository, the commit log (which might shake up in format...) should capture relatively complete transactions of either a particular feature or comparable additions, deletions, or modifications. That said, there may be little fixes in later commits of edits that really should've been in other ones, and the toc and index accuracy at any given commit is dubious at best. However, the content of the pages themselves should be pretty well broken up in to noteworthy transactions. If you find a problem or have a correction, feel free to send it my way or even better, open a pull request with an explanation for the change. This repository will accrete more UNIX releases as time goes on, with a first goal being getting to V6, after which the fragmentary pathways will be a little harder to reconcile to a single informative trunk. I might start branches at that point. By the way, in this process I found that the V2 manual scanned by Dennis Ritchie [1] contains references to nroff(I) in the TOC and permuted index, but the page may not have been in his copy. Given this, just to not hang up on it, I simply dropped in the V3 page with a note about this in the BUGS section. 1 - https://www.tuhs.org/Archive/Distributions/Research/Dennis_v2/v2man.pdf - Matt G. From marc.donner at gmail.com Tue Apr 4 03:55:02 2023 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 3 Apr 2023 13:55:02 -0400 Subject: [TUHS] Warning: April Fools In-Reply-To: <2f3bf40b-af75-f899-58a1-611b8c52a8c7@gmail.com> References: <2148ce0c-e49d-8789-d632-1c3ec27698e8@gmail.com> <2f3bf40b-af75-f899-58a1-611b8c52a8c7@gmail.com> Message-ID: And for you history nerds, there's an interesting new life of Charlemagne out from the UC Press ( https://www.ucpress.edu/book/9780520383210/king-and-emperor). It's a heavy slog but fascinating. ===== nygeek.net mindthegapdialogs.com/home On Sun, Apr 2, 2023 at 9:46 AM Harald Arnesen wrote: > Wesley Parish [02/04/2023 13.18]: > > > It's referring to King Chuck the Great, Karl der Gross, Charlemagne. Or > > if you like, the Great and Magnificent King Upchuck. :) ) > > Karlamagnus, as the vikings called him. > -- > Hilsen Harald > Слава Україні! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From royce at techsolvency.com Wed Apr 5 14:35:18 2023 From: royce at techsolvency.com (Royce Williams) Date: Tue, 4 Apr 2023 20:35:18 -0800 Subject: [TUHS] administrivia: redirects from minnie? Message-ID: I see that all the old minnie links: https://minnie.tuhs.org/pipermail/* ... break, and archived post are now at: https://www.tuhs.org/pipermail/* Could we get a courtesy redirect for pipermail/* ? -- Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Apr 6 06:35:06 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 5 Apr 2023 16:35:06 -0400 Subject: [TUHS] 2.9BSD PUCC Message-ID: Hello all, I am working on restoring the 2.9BSD PUCC distribution as provided on the CSRG CD/DVD set, hopefully as closely as possible to the original system. I am at a point where I have a setup that boots 95% of the way to multiuser but I have encountered some difficulties with the final few steps. I would appreciate it if anyone who is familiar with the login procedure could contact me off-list. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Apr 7 06:49:52 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 6 Apr 2023 16:49:52 -0400 Subject: [TUHS] Warren Toomey interviewed by Rik Farrow. Message-ID: Enjoy this interview with our own wkt! https://www.usenix.org/publications/loginonline/interview-warren-toomey-founder-unix-heritage-society From lars at nocrew.org Sat Apr 8 04:00:13 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 07 Apr 2023 18:00:13 +0000 Subject: [TUHS] CWRU Univac artifacs Message-ID: <7wo7nzshci.fsf@junk.nocrew.org> Hello, I received word from someone who went to Case Wester Reserve Univsersity, and is willing to send early 1970s ephemera to someone interested in going through it. The description is: "I've go stuff from my course work done on our Univac 1108/ChiOS system, program listing, cpu code cards, etc." Any takers? Best regards, Lars Brinkhoff From cowan at ccil.org Sat Apr 8 07:35:11 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 7 Apr 2023 17:35:11 -0400 Subject: [TUHS] CWRU Univac artifacs In-Reply-To: <7wo7nzshci.fsf@junk.nocrew.org> References: <7wo7nzshci.fsf@junk.nocrew.org> Message-ID: I attended CRWU in 1975-76 and programmed the 1108 (abs, alphabetic, arccos, arcsin, arctan) with punch cards so I am definitely interested if the material is still available. On Fri, Apr 7, 2023 at 2:00 PM Lars Brinkhoff wrote: > Hello, > > I received word from someone who went to Case Wester Reserve > Univsersity, and is willing to send early 1970s ephemera to someone > interested in going through it. The description is: > > "I've go stuff from my course work done on our Univac 1108/ChiOS system, > program listing, cpu code cards, etc." > > Any takers? > > Best regards, > Lars Brinkhoff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Apr 8 17:16:02 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 08 Apr 2023 07:16:02 +0000 Subject: [TUHS] CWRU Univac artifacs In-Reply-To: (John Cowan's message of "Fri, 7 Apr 2023 17:35:11 -0400") References: <7wo7nzshci.fsf@junk.nocrew.org> Message-ID: <7w7cumsv2l.fsf@junk.nocrew.org> Apologies, this was meant to go to another mailing list. I also posted to COFF, so send any follow-ups there. John Cowan wrote: > I attended CRWU in 1975-76 and programmed the 1108 (abs, alphabetic, arccos, > arcsin, arctan) with punch cards so I am definitely interested if the > material is still available. Thank you, I'll fill you in on the details. From tuhs at tuhs.org Sun Apr 9 02:33:00 2023 From: tuhs at tuhs.org (Aaron Jackson via TUHS) Date: Sat, 08 Apr 2023 17:33:00 +0100 Subject: [TUHS] Latest 2.9BSD and 2.11BSD In-Reply-To: <20200528214954.GA22861@minnie.tuhs.org> References: <20200528214954.GA22861@minnie.tuhs.org> Message-ID: <877cumfgmu.fsf@carbon.rhwyd.co.uk> Warren Toomey writes: >> I see we have 2.11BSD patch 469 dated last month in the archive. Where >> does it come from? Has anybody climbed the hill to import all the >> patches into a git repo? > > I know somebody tried a while back and reported here. They found it wasn't > possible to apply all the patches sequentially. I'd have to go look in > the mail archive for details. > > Maybe it's time for someone else to have a go! > > Cheers, Warren Stumbled upon this email thread while searching my inbox for some patch info. I've managed to setup an automated pipeline for applying all patches sequentially, producing a new disk image after each one. This has been built as a GitHub workflow, and the images are then pushed up to an S3 bucket for others to use. https://github.com/AaronJackson/2.11BSD-Action At the very least, it is confirmation and verification that the released patches can be applied sequentially, and each one leaves the system in a bootable state, if applied correctly. I've also been applying the patches to a fork of the source tree on GitHub which Warner Losh created (maybe after this email thread). I've been doing this in the patch-apply2023 branch but it's a bit of a mess at the moment and doesn't build. The repo also includes an IBV11 card driver which I wrote with the help of Toby Thain. I'm not sure whether Steven would welcome patches for new features, rather than bug fixes, but I'd be happy to generate a patch file if others wanted to control their "modern" test gear from their PDP11. https://github.com/AaronJackson/2.11BSD At some point I'm planning to automate the process of generating the installation tapes for each patch level. Not got round to this though, yet - although it's Easter weekend, so I might have a play. Cheers, Aaron -- https://aaronsplace.co.uk From imp at bsdimp.com Sun Apr 9 03:09:30 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 8 Apr 2023 11:09:30 -0600 Subject: [TUHS] Latest 2.9BSD and 2.11BSD In-Reply-To: <877cumfgmu.fsf@carbon.rhwyd.co.uk> References: <20200528214954.GA22861@minnie.tuhs.org> <877cumfgmu.fsf@carbon.rhwyd.co.uk> Message-ID: On Sat, Apr 8, 2023, 11:06 AM Aaron Jackson wrote: > > Warren Toomey writes: > > >> I see we have 2.11BSD patch 469 dated last month in the archive. > Where > >> does it come from? Has anybody climbed the hill to import all the > >> patches into a git repo? > > > > I know somebody tried a while back and reported here. They found it > wasn't > > possible to apply all the patches sequentially. I'd have to go look in > > the mail archive for details. > > > > Maybe it's time for someone else to have a go! > > > > Cheers, Warren > > Stumbled upon this email thread while searching my inbox for some patch > info. I've managed to setup an automated pipeline for applying all > patches sequentially, producing a new disk image after each one. This > has been built as a GitHub workflow, and the images are then pushed up > to an S3 bucket for others to use. > > https://github.com/AaronJackson/2.11BSD-Action > > At the very least, it is confirmation and verification that the released > patches can be applied sequentially, and each one leaves the system in a > bootable state, if applied correctly. > > I've also been applying the patches to a fork of the source tree on > GitHub which Warner Losh created (maybe after this email thread). I've > been doing this in the patch-apply2023 branch but it's a bit of a mess > at the moment and doesn't build. The repo also includes an IBV11 card > driver which I wrote with the help of Toby Thain. I'm not sure whether > Steven would welcome patches for new features, rather than bug fixes, > but I'd be happy to generate a patch file if others wanted to control > their "modern" test gear from their PDP11. > > https://github.com/AaronJackson/2.11BSD > > At some point I'm planning to automate the process of generating the > installation tapes for each patch level. Not got round to this though, > yet - although it's Easter weekend, so I might have a play. > Any chance you could extend this to my work to recreate the 2.11 as released tapes? There are extra challenges in the first 200 patches, including missing patches... Warner Cheers, > Aaron > > > -- > https://aaronsplace.co.uk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Apr 9 03:22:35 2023 From: tuhs at tuhs.org (Aaron Jackson via TUHS) Date: Sat, 08 Apr 2023 18:22:35 +0100 Subject: [TUHS] Latest 2.9BSD and 2.11BSD In-Reply-To: References: <20200528214954.GA22861@minnie.tuhs.org> <877cumfgmu.fsf@carbon.rhwyd.co.uk> Message-ID: <87355afftd.fsf@carbon.rhwyd.co.uk> > Warren Toomey writes: > > >> I see we have 2.11BSD patch 469 dated last month in the archive. Where > >> does it come from? Has anybody climbed the hill to import all the > >> patches into a git repo? > > > > I know somebody tried a while back and reported here. They found it wasn't > > possible to apply all the patches sequentially. I'd have to go look in > > the mail archive for details. > > > > Maybe it's time for someone else to have a go! > > > > Cheers, Warren > > Stumbled upon this email thread while searching my inbox for some patch > info. I've managed to setup an automated pipeline for applying all > patches sequentially, producing a new disk image after each one. This > has been built as a GitHub workflow, and the images are then pushed up > to an S3 bucket for others to use. > > https://github.com/AaronJackson/2.11BSD-Action > > At the very least, it is confirmation and verification that the released > patches can be applied sequentially, and each one leaves the system in a > bootable state, if applied correctly. > > I've also been applying the patches to a fork of the source tree on > GitHub which Warner Losh created (maybe after this email thread). I've > been doing this in the patch-apply2023 branch but it's a bit of a mess > at the moment and doesn't build. The repo also includes an IBV11 card > driver which I wrote with the help of Toby Thain. I'm not sure whether > Steven would welcome patches for new features, rather than bug fixes, > but I'd be happy to generate a patch file if others wanted to control > their "modern" test gear from their PDP11. > > https://github.com/AaronJackson/2.11BSD > > At some point I'm planning to automate the process of generating the > installation tapes for each patch level. Not got round to this though, > yet - although it's Easter weekend, so I might have a play. Warner Losh writes: > Any chance you could extend this to my work to recreate the 2.11 as > released tapes? There are extra challenges in the first 200 patches, > including missing patches... > > Warner If you are talking about this: https://github.com/bsdimp/mk211bsd I'll take a look and see - that does sound like a mess to sort out though :D cheers, Aaron From imp at bsdimp.com Sun Apr 9 03:26:16 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 8 Apr 2023 11:26:16 -0600 Subject: [TUHS] Latest 2.9BSD and 2.11BSD In-Reply-To: <87355afftd.fsf@carbon.rhwyd.co.uk> References: <20200528214954.GA22861@minnie.tuhs.org> <877cumfgmu.fsf@carbon.rhwyd.co.uk> <87355afftd.fsf@carbon.rhwyd.co.uk> Message-ID: On Sat, Apr 8, 2023, 11:23 AM Aaron Jackson wrote: > > Warren Toomey writes: > > > > >> I see we have 2.11BSD patch 469 dated last month in the archive. > Where > > >> does it come from? Has anybody climbed the hill to import all the > > >> patches into a git repo? > > > > > > I know somebody tried a while back and reported here. They found it > wasn't > > > possible to apply all the patches sequentially. I'd have to go look in > > > the mail archive for details. > > > > > > Maybe it's time for someone else to have a go! > > > > > > Cheers, Warren > > > > Stumbled upon this email thread while searching my inbox for some patch > > info. I've managed to setup an automated pipeline for applying all > > patches sequentially, producing a new disk image after each one. This > > has been built as a GitHub workflow, and the images are then pushed up > > to an S3 bucket for others to use. > > > > https://github.com/AaronJackson/2.11BSD-Action > > > > At the very least, it is confirmation and verification that the released > > patches can be applied sequentially, and each one leaves the system in a > > bootable state, if applied correctly. > > > > I've also been applying the patches to a fork of the source tree on > > GitHub which Warner Losh created (maybe after this email thread). I've > > been doing this in the patch-apply2023 branch but it's a bit of a mess > > at the moment and doesn't build. The repo also includes an IBV11 card > > driver which I wrote with the help of Toby Thain. I'm not sure whether > > Steven would welcome patches for new features, rather than bug fixes, > > but I'd be happy to generate a patch file if others wanted to control > > their "modern" test gear from their PDP11. > > > > https://github.com/AaronJackson/2.11BSD > > > > At some point I'm planning to automate the process of generating the > > installation tapes for each patch level. Not got round to this though, > > yet - although it's Easter weekend, so I might have a play. > > Warner Losh writes: > > > Any chance you could extend this to my work to recreate the 2.11 as > > released tapes? There are extra challenges in the first 200 patches, > > including missing patches... > > > > Warner > > If you are talking about this: > https://github.com/bsdimp/mk211bsd > > I'll take a look and see - that does sound like a mess to sort out > though :D > Yes. It's why I've not done it yet. Going backwards was hard enough :) I'd love to help, but don't have the time to drive it. Warner > cheers, > Aaron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Apr 11 04:27:51 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 10 Apr 2023 18:27:51 +0000 Subject: [TUHS] UNIX "Machine Layer" Standards Message-ID: Good day everyone. I'm taking a bit of a break from my documentation stuff and veering back towards some embedded systems work and have the burning question on my mind this morning: Was there any coordination between different groups engaged in porting efforts at Bell regarding machine layer implementations? In other words, was there any sort of common design of "get a stack pointer, do on the protection hardware, move the binary to address , clear bss, etc." that was followed as lore when working up new machine bootstraps, or was that sort of work a bit more siloed? For instance, when working on the VAX port, was the crew more likely stepping through mch replicating things based on what the PDP-11 was doing, was the startup more derived from DEC literature, 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? 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. What I don't know is if I'm barking up the wrong tree and it was already settled in the 70s that machines are sufficiently different enough that you can't really just set forth one abstract "machine startup" design that actually includes all those CPU-level concerns such as protection, stack config, context switching, etc. I know even today peering into sources of stuff like Linux and seL4, the "ml" for each seems to have been built by a different person/group rather than someone setting out with a CPU bootstrap design and implementing the same on each chip. So boiled down to a one liner: Was there a guiding document/design/memoranda for the mch/ml components of UNIX in Bell, or was each one designed more "on-the-fly" as the particulars of the hardware were sorted out? - Matt G. From rich.salz at gmail.com Wed Apr 19 03:05:16 2023 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 18 Apr 2023 17:05:16 -0000 Subject: [TUHS] Free books Message-ID: I figure it won't cost me much more than $5 to ship domestically, which I'll pay for. International is more hassle so let's discuss. BSTJJuly-August 1978 ("the" issue) Elements of Programming Style 2nd Ed, Kernighan and Plauger The UNIX Programming Environment, Kernighan and Pike The C Programming Language 2nd Ed, Kernighan and Ritchie (includes printout of errata posted by dmr at alice.JUCP "5 Jun 89") -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at keck.us Wed Apr 19 03:07:16 2023 From: tuhs at keck.us (Cornelius Keck) Date: Tue, 18 Apr 2023 17:07:16 -0000 Subject: [TUHS] Free books In-Reply-To: References: Message-ID: <60affc8c-e2d9-821a-002d-fbe5f610012a@keck.us> If they are not already spoken for, I'd like them. -Cornelius On 2023-04-18 12:04, Rich Salz wrote: > I figure it won't cost me much more than $5 to ship domestically, which > I'll pay for. International is more hassle so let's discuss. > > BSTJJuly-August 1978 ("the" issue) > > Elements of Programming Style 2nd Ed, Kernighan and Plauger > > The UNIX Programming Environment, Kernighan and Pike > > The C Programming Language 2nd Ed, Kernighan and Ritchie (includes > printout of errata posted by dmr at alice.JUCP "5 Jun 89") > From rich.salz at gmail.com Wed Apr 19 03:12:51 2023 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 18 Apr 2023 17:12:51 -0000 Subject: [TUHS] Free books In-Reply-To: References: Message-ID: All gone. On Tue, Apr 18, 2023 at 1:04 PM Rich Salz wrote: > I figure it won't cost me much more than $5 to ship domestically, which > I'll pay for. International is more hassle so let's discuss. > > BSTJJuly-August 1978 ("the" issue) > > Elements of Programming Style 2nd Ed, Kernighan and Plauger > > The UNIX Programming Environment, Kernighan and Pike > > The C Programming Language 2nd Ed, Kernighan and Ritchie (includes > printout of errata posted by dmr at alice.JUCP "5 Jun 89") > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.fujino at gmail.com Wed Apr 19 12:28:00 2023 From: christopher.fujino at gmail.com (christopher fujino) Date: Wed, 19 Apr 2023 02:28:00 -0000 Subject: [TUHS] Free books In-Reply-To: References: Message-ID: :'( On Tue, Apr 18, 2023 at 10:12 AM Rich Salz wrote: > All gone. > > On Tue, Apr 18, 2023 at 1:04 PM Rich Salz wrote: > >> I figure it won't cost me much more than $5 to ship domestically, which >> I'll pay for. International is more hassle so let's discuss. >> >> BSTJJuly-August 1978 ("the" issue) >> >> Elements of Programming Style 2nd Ed, Kernighan and Plauger >> >> The UNIX Programming Environment, Kernighan and Pike >> >> The C Programming Language 2nd Ed, Kernighan and Ritchie (includes >> printout of errata posted by dmr at alice.JUCP "5 Jun 89") >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Apr 20 04:55:57 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 19 Apr 2023 18:55:57 -0000 Subject: [TUHS] UNIX Manual Cover Art Origins? Message-ID: <0DgApyEhpkfAx8pFuMLETqwtbpvkVIg731BxCR78gbiPGJbJqrTO3_IoOTIPgsecR1fwhoMND4M5YW3dDBfDzUUOeHNFlcp4DwkveMHXk10=@protonmail.com> Good day everyone, I'm in search of a bit of esoteric information regarding published UNIX works. Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? Some that come to mind: The alphabet blocks cover of the HRW V7 Manuals The simple 70's Bell-style cover of the UNIX System III manual The nice 3B-20 picture on the UNIX 4.1 manual The grid patterns design on the UNIX System V documentation The blue "big V" SVR4 manuals (given the time disparity, these could have totally different underpinnings) Where I'm particularly curious is how these covers were actually set, defined, the image data to print on them stored, formatted, etc. In other words, :troff::covers:manpages where ??? may also represent more than just the specific tools/formats. Anyone have the scoop on the actual raw materials and technologies used for preparing the covers and/or if any of those original assets, in their raw form, would potentially still exist somewhere? To be honest, I am particularly interested in the original, highest fidelity possible image of the 3B-20 from the corresponding manual (https://commons.wikimedia.org/wiki/Category:Unix_Manuals#/media/File:UNIX4.1UsersManualCover.png) but am happy with any info illuminates what went into the actual physical production. Thanks all! - Matt G. P.S. If it provides any leads, the closest thing I've found in actual document sources to material related to these aspects of physical publication are the files M.folio and M.tabs here: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/tools From douglas.mcilroy at dartmouth.edu Thu Apr 20 06:11:17 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 19 Apr 2023 20:11:17 -0000 Subject: [TUHS] UNIX Manual Cover Art Origins? Message-ID: > Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? The Bell Labs publication department at Whippany did the physical design for the bound versions of the Research Unix manual--from v7 as a trade brook through v10, also a trade book.. They did the cover designs for v8-v10 in house. I am not sure whether they did the v7 cover, farmed it out, or left it up to Holt Rinehart. Whippany handled the printing of v8 and v9. Saunders College Publishing did it for v10. Unfortunately, I do not remember whom I dealt with in Whippany, and my records of the interactions are long gone. Doug From tuhs at tuhs.org Thu Apr 20 15:09:10 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 20 Apr 2023 05:09:10 -0000 Subject: [TUHS] UNIX SVR2 User's Manual BTL Edition Additions and References Message-ID: Good evening, I'd like to share a listing I've taken of the various extra pages present in the BTL version of the SVR2 User's Manual I picked up a little while ago. https://pastebin.com/18uTzyfS Like the Release 5.0 BTL version before it, many of the added pages are DIV 452 standard pages for Writer's Workbench as well as the Basic-16/BELLMAC-4/BELLMAC-8 development environments. To quote the preface: "This manual was designed through a cooperative effort of the BTL Computer Centers in Division 452. It represents a collection of nearly all the commands that are running on any Computer Center UNIX machine. ... The header of each manual page identifies the classification of the command along with any machine or site dependencies. ... Any page marked LOCAL indicates the sites that are running that command. ... Pages marked DIV 452 STD are from the collection of Computer Center standard commands, and are available on machines administered by Division 452 Computer Centers. The pages that are designated as INTERIM or 5.0 are those commands which are scheduled to be included in a separate WECo software add-on package." This manual is just sections 1 and 6, presumably 1m, 7, and 8 are in a corresponding administrator's manual and 2, 3, 4, 5 are in a programmer's manual, making SVR2 the start of the user's manual being further subdivided. I seem to recall one or the other of this same issue of manuals show up on eBay at some point, I'm kicking myself for not springing for it at the time, but hopefully one or the other (or both) turn up again to be documented someday. Additionally included in the above listing is a list of references from various "SEE ALSO" sections throughout the manual, as well as some other odds and ends from the text. Finally, there is a short listing of teach(1) classes as provided by a couple variants of the application. If any particular page piques an interest, let me know and I can scan it for you, otherwise this one is a ways away on my scan backlog. - Matt G. From tuhs at tuhs.org Thu Apr 20 15:25:15 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 20 Apr 2023 05:25:15 -0000 Subject: [TUHS] UNIX Manual Cover Art Origins? In-Reply-To: References: Message-ID: Thanks for the info Doug! That certainly gave me somewhere to start. After stepping through the circa 1983 BTL SVR2 manual, the only Whippany-specific pages I found related to a "DI-3000" printing system from Precision Visuals. The cover of the referenced manual is on Google Books, but I can't seem to find a scanned copy. Whether it would've been related, couldn't say. Much of what I can find on DI-3000 is advertising materials and articles about specific applications, but no general user material. I'm glad to have the V7 and V10 editions on hand, but I didn't know V8 and V9 also saw print release, although just now searching I did find what appeared to be a comb-bound print of V8, but couldn't find a second source for the image (https://media.licdn.com/dms/image/C5112AQHO14UEpqFPPQ/article-cover_image-shrink_600_2000/0/1520220760198?e=2147483647&v=beta&t=Rt8IyYB6GgD5RIBjBAjwP8hgcxcuKML0BwIxgzhLW0M). Anywho, I'll add DI-3000 to my list of things to comb for history of every now and then, maybe something cool will pop up. - Matt G. ------- Original Message ------- On Wednesday, April 19th, 2023 at 1:10 PM, Douglas McIlroy wrote: > > Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? > > > The Bell Labs publication department at Whippany did the physical > design for the bound versions of the Research Unix manual--from v7 as > a trade brook through v10, also a trade book.. They did the cover > designs for v8-v10 in house. I am not sure whether they did the v7 > cover, farmed it out, or left it up to Holt Rinehart. Whippany handled > the printing of v8 and v9. Saunders College Publishing did it for v10. > > Unfortunately, I do not remember whom I dealt with in Whippany, and my > records of the interactions are long gone. > > Doug From arnold at skeeve.com Thu Apr 20 20:39:11 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 20 Apr 2023 10:39:11 -0000 Subject: [TUHS] UNIX Manual Cover Art Origins? In-Reply-To: References: Message-ID: <202304201038.33KAcmRk028500@freefriends.org> segaloco via TUHS wrote: > I'm glad to have the V7 and V10 editions on hand, but I > didn't know V8 and V9 also saw print release, although just > now searching I did find what appeared to be a comb-bound > print of V8, V8 and V9 were printed for internal use. In the mid-90s I managed to get a copy of the V8 manual via Brian Kernighan, and then I paid $50 (IIRC) for the V9 manual - I corresponded with Doug about it who had to check if they could actually sell me one. :-) Arnold From pnr at planet.nl Fri Apr 21 00:56:55 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 20 Apr 2023 14:56:55 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards Message-ID: > 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. From 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’s. 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: - “low.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. - “mch.s” (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 ‘missing’ 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’s and early 80’s. - low-level device drivers live in the ‘dmr’ or (later) ‘io’ 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’ 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’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ subsystem. - I don’t think there was ever anything in early Unix that merged ’streams’ 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’ll respond to this with a pm. From pnr at planet.nl Fri Apr 21 01:57:29 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 20 Apr 2023 15:57:29 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards Message-ID: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> Hi Matt, I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well. > 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, working with early Unix and modern RiscV hardware for a compare and contrast experience. - My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V. - My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment. My ideas are still evolving, but currently more or less along the below lines: - Boot rom loads SPL, this is custom in each case and set by the SoC's designers. - SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary. - The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console). - The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation. At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above. From imp at bsdimp.com Fri Apr 21 02:04:41 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 20 Apr 2023 16:04:41 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: References: Message-ID: On Thu, Apr 20, 2023 at 8:56 AM Paul Ruizendaal 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 > 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. From 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’s. 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: > > - “low.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. > 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. - “mch.s” (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 ‘missing’ 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’s and early 80’s. > 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 ‘dmr’ or (later) ‘io’ 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 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’ > 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’s (the splicing in, not the writing of the file system itself, of > course). Starting with 8th edition, the ‘file system switch’ created a > clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also > a ‘high-level device driver’, but this one lives as custom code together > with the serial port device drivers. Also in 8th Edition, ‘streams' were > introduced. One could think of this as a structured approach to high-level > device drivers for character mode devices, incl. the ’tty’ 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’t think there was ever anything in early Unix that merged > ’streams’ and the 'file system switch' into a single abstraction (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’ll respond to this with a pm. > I'd be keen to understand this, but it's mostly a passing fancy... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Apr 21 04:57:53 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 20 Apr 2023 18:57:53 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> References: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> Message-ID: <5A9q989Xqp3qAU5v84HciEjrFF9tcvviKQYlxhwTCbnDjEARnMx_BtNkzqXR_0Y0nAkzCdaSR6KGqWCQgwjUW_ydfz6iQSFKRvTnhGiqyc0=@protonmail.com> The funny thing is what literally started all of this is I wanted to update the firmware on my VisionFive, followed their instructions to a T, and it bricked the firmware. I found that the embedded recovery ROM still worked, so then tried to follow their processes to reflash the bootloader/SBI stuff. That likewise failed, so I gave up on trusting any of their documentation/advice and just started hacking on the thing with binaries sent over XMODEM on the serial line. Their XMODEM-CRC implementation is broken so I even had to write my own version of sx (they had a XMODEM send, likewise doesn't work stock...got it to work modified but then just wrote a simple stdio tool without all the cruft of their implementation.) Fast forward to today and the most I've put together for that is this: https://gitlab.com/segaloco/riscv-bits (src is "kernel" stuff, util is that XMODEM-CRC transfer thing I mentioned) I've got some process handling and VM stuff that hasn't gone up to the repo yet, but it's hanging around because it's incomplete anyway. I then realized with what I'd learned in the process I was poised to start hacking on other SBCs at that level, so ordered the Pico, Ox64, and an Onion Omega2 (ARM32, RV64, and MIPS32 respectively) and have slowly been building up development workflows for each (I'm eschewing vendor libraries and SDKs given my experiences with the VisionFive...) The boot matter itself is proving the most annoying part, since literally each one of those has a different mechanism to get an operational binary loaded up. VisionFive is an (broken) XMODEM-CRC transfer, Pico is a UF2 file over USB, Ox64 is some custom Bouffalo Lab tool (although I think it's just a wrapper on top of some standard XMODEM/Kermit/etc. type protocol), and then the Omega2 I haven't even really explored raw boot yet, it's got OpenWRT on it so I've just been hacking on the existing OS thus far, getting more familiar with the board, my hunch is it's probably a UF2-ish thing since it's main UART is over USB like the Pico. RISC-V presents some complications given the privilege model, what with the "master" mode vs the "supervisor" mode, as opposed to other chips where supervisor and master are essentially one in the same. Where I'm torn is if I want to have OpenSBI in the mix just to go with what is ubiquitous in RISC-V land, or even try to handle that matter with my own code. That wouldn't necessarily have an analog on all the other platforms. Then there's hypervisor stuff, what with RISC-V having the extension and other chips having something akin to this, but it not being universal. The simple answer is to just get everything, regardless of details into a "supervisor" state, ensure necessary interrupts are forwarded to this state if another, higher one exists, and enter into this supervisor state with MMU/VM turned off. Then theoretically each machine can start from here by setting up memory, then device inits, then FS and other subsystem init, and finally process init. Anywho, I'm kinda at a standstill on this project right now while I work on a few other things, namely a disassembly of Dragon Quest for the Famicom (embedded console games are a lot like operating systems) and manual page diffing stuff, but I'm hoping to carve out some time this summer, maybe even a little coding retreat from work for a few weeks, to hammer out a true project plan on paper so I can start working on more of this in earnest. I'm not sure yet if I'll be headed down the "get UNIX going" or "get my kernel going" route first when I get there, but either way, I'm sure we'll have plenty to talk about in the coming year. - Matt G. ------- Original Message ------- On Thursday, April 20th, 2023 at 8:57 AM, Paul Ruizendaal wrote: > Hi Matt, > > I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well. > > > 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, working with early Unix and modern RiscV hardware for a compare and contrast experience. > > - My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V. > > - My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII > > Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment. > > > My ideas are still evolving, but currently more or less along the below lines: > > - Boot rom loads SPL, this is custom in each case and set by the SoC's designers. > > - SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary. > > - The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console). > > - The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation. > > At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above. > > > > > > From tuhs at tuhs.org Fri Apr 21 05:05:14 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 20 Apr 2023 19:05:14 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: References: Message-ID: The off-list reply (and reply to reply) wound up on list...my bad for not checking Cc list, but in any case, if any real developments come of things I'm tinkering on, I'll be sure to share them back. Thanks for the analysis Warner, BSD and Bell do present two interesting approaches to the abstraction matter. What makes things difficult is there aren't a lot of good examples of "multi-target" Bell source trees whereas with BSDs you have single source code packages that have multiple "machine layer" instances present. For instance, all the System V code I've seen floating around typically only has one variant of the kernel in the /usr/src folder, whereas you go into the machine layer on any BSD and you're bound to see the list of architectures and associated code being supported at the time. I suspect this was policy in the Bell UNIX group that the source provided with a given tape was for the architecture it was destined for, rather than /usr/src containing the entire port tree. Of course, this is just speculation, if someone knows the truth, I'm certainly curious how that sort of thing was organized/managed. - Matt G. P.S. sorry for the reply alls on the other fork of this thread, actually meant to not do that... ------- Original Message ------- On Thursday, April 20th, 2023 at 9:04 AM, Warner Losh wrote: > On Thu, Apr 20, 2023 at 8:56 AM Paul Ruizendaal 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 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. From 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’s. 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: >> >> - “low.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. > > 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. > >> - “mch.s” (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 ‘missing’ 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’s and early 80’s. > > 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 ‘dmr’ or (later) ‘io’ 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 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’ 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’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ 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’t think there was ever anything in early Unix that merged ’streams’ and the 'file system switch' into a single abstraction (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’ll respond to this with a pm. > > I'd be keen to understand this, but it's mostly a passing fancy... > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Apr 21 06:18:37 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 20 Apr 2023 20:18:37 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: <5A9q989Xqp3qAU5v84HciEjrFF9tcvviKQYlxhwTCbnDjEARnMx_BtNkzqXR_0Y0nAkzCdaSR6KGqWCQgwjUW_ydfz6iQSFKRvTnhGiqyc0=@protonmail.com> References: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> <5A9q989Xqp3qAU5v84HciEjrFF9tcvviKQYlxhwTCbnDjEARnMx_BtNkzqXR_0Y0nAkzCdaSR6KGqWCQgwjUW_ydfz6iQSFKRvTnhGiqyc0=@protonmail.com> Message-ID: On Thu, 20 Apr 2023, segaloco via TUHS wrote: > Anywho, I'm kinda at a standstill on this project right now while I work > on a few other things, namely a disassembly of Dragon Quest for the > Famicom (embedded console games are a lot like operating systems) and > manual page diffing stuff, but I'm hoping to carve out some time this > summer, maybe even a little coding retreat from work for a few weeks, to > hammer out a true project plan on paper so I can start working on more > of this in earnest. I'm not sure yet if I'll be headed down the "get > UNIX going" or "get my kernel going" route first when I get there, but > either way, I'm sure we'll have plenty to talk about in the coming year. Funny you mention Dragon Warrior, that's been something that's breaking my brain from two different directions lately (since I'm trying to port it to the Apple //e and the Nabu, and I'm completely in the weeds for both). XD I haven't worked much on my own Unix stuff lately because the Nabu stuff's taken a lot of my brainpower. -uso. From jnc at mercury.lcs.mit.edu Sat Apr 22 00:37:32 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 21 Apr 2023 14:37:32 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards Message-ID: <20230421143713.492DF18C0A3@mercury.lcs.mit.edu> > From: Paul Ruizendaal > something like a boot rom only became the norm in the late > 70's. Before that, one keyed in two dozen words with a tiny program to > load the first boot stage. A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot ROM: https://gunkies.org/wiki/BM792_ROM which appreared in mid-1971 (about a year after the release of the /20). DEC sold them pre-programmed, but one could 'program' one onself, if one wanted - with a soldering iron! (Check out the image! I actually did that to one that I was given, that had been eviscerated by someone.) From then on (follow the category link), the rest used PROM chips. > From: Warner Losh > Oftentimes, the interrupt vector was in the lowest core addresses It's worth remembering that in the early period, that restriction to low addresses was built into the hardware (in an amusing way :-). Take the DL11: https://gunkies.org/wiki/DL11_asynchronous_serial_line_interface which was sort of mandatory as the 'console' serial interface on most early -11's (until the DL11-W appeared; more on its big improvement in a second). It set the interrupt vector with _jumpers_. (You want to change the interrupt vector? Dig out your soldering iron! :-) There were only 6 jumpers - one each for address bits 3 through 8. So the largest vector you could set was 0770. The DL11-W was a big step forward - it replaced the jumpers with a DIP switch! :-) Still only six bits, though. :-) Noel From cowan at ccil.org Sat Apr 22 03:58:34 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 21 Apr 2023 17:58:34 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: <20230421143713.492DF18C0A3@mercury.lcs.mit.edu> References: <20230421143713.492DF18C0A3@mercury.lcs.mit.edu> Message-ID: On Fri, Apr 21, 2023 at 10:37 AM Noel Chiappa wrote: > A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot > ROM: > The PDP-8/E, which came out in the same year, had a boot ROM if you were using DECtape as the system device for OS/8. The bootstrap for the TD8E DECtape controller was a full device driver 128 words long, way beyond human toggle-in capability. It was put up in addresses 77600-77777, which meant that you could only have 28 kwords rather than the full 32 kwords of RAM. In principle I suppose you could have toggled in the RIM loader (17 words) and read in the TD8E bootstrap using either Model 33 or high-speed paper tape, but I doubt if anyone did that. RIM format alternated between addresses and values, with each taking up two characters on the paper tape. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Apr 22 06:36:48 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 21 Apr 2023 20:36:48 -0000 Subject: [TUHS] UNIX "Machine Layer" Standards In-Reply-To: References: <20230421143713.492DF18C0A3@mercury.lcs.mit.edu> Message-ID: On Fri, Apr 21, 2023 at 1:58 PM John Cowan wrote: > In principle I suppose you could have toggled in the RIM loader (17 words) > and read in the TD8E bootstrap using either Model 33 or high-speed paper > tape, but I doubt if anyone did that. RIM format alternated between > addresses and values, with each taking up two characters on the paper tape. > I can't speak for an 8/E or OS/8, for that matter. As I recall, the machine (single Digital serial # - original 8) that TSS/8 was originally developed used the RIM loader to load the disk bootstrap. I remember a paper tape on the console ASR-33 and then toggling the RIM loader., etc. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Apr 24 03:45:48 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 23 Apr 2023 17:45:48 -0000 Subject: [TUHS] S2-bits V2 Source Code Restoration Message-ID: Hi folks, sharing another project that I've been tinkering on for a little bit since I like having a lot of irons in the fire: https://gitlab.com/segaloco/v2src After the link is a repository which over time will be accumulating the results of disassembly and analysis of files found in the s2-bits.tar.gz file in the archive. Details of my process are contained in the repository's readme. The short of it is I'm disassembling the binaries one by one, and where possible am comparing them with known sources to massage these into a pretty close restoration of the original sources. A few discoveries I've made in the process thus far: - These binaries appear to represent a version between the first and second editions. The binaries themselves are a mix of "naked" binaries as well as V1 and V2 a.out formats. Where it matters, things are much closer in character to V2 than V1. - All section 1 content that would be gone by V2 is removed here. Curiously, mount(1), type(1), and umount(1) which are in both V1 and V2 are absent from the s2-bits. - The sources marked "V2" in the UNIX source tree may be a bit closer in character to V3. Notable examples are that, while string references to /etc/uids remain, all data references have been updated to /etc/passwd, and several mathematical operations in the disassembled binaries map to KE-11 Extended Arithemtic Element registers where in the sources labeled "V2" in the tree have instead shifted to doing these calculations differently, presumably as these sources target the 11/45, not the 11/20. Additionally, the cat.s in "V2" on the tree contains the '-' stdin option, which was first documented in V3. The most likely story is that they're somewhere between, just like the s2-bits are between V1 and V2, but all of these observed differences thus far have aligned the sources with their descriptions in the third edition manual. Anywho, as usual, if anyone spots anything amiss or that could be done better, happy to accept contributions, or fork it and tinker away. Also, if anyone has already done this, speak up and tell me now so I don't double up on something so involved =P - Matt G.