TUHS July 2022

tuhs@tuhs.org

63 participants
40 discussions

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh >> What's "net unix" anyway? > I'm referring to the University of Illinois distribution Ah, OK. > I have seen references to it in the ARPAnet census documents running on > both V6 and V7 (though mostly they were silent about which version). Well, V7 came out in January, 1979, and NCP wasn't turned off until January, 1983, so people had a lot of time to get it running under V7. > I thought this was the normal nomenclature of the time, but I may be > mistaken. I'm not sure what it was usually called; we didn't have much contact with it at MIT (although I had the source; I'm the one that provided it to TUHS). The problem was that although MIT had two IMPs, all the ports on them were spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1 running TWENEX; a Multics), so there were no ports available to plug in a lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix (which I vaguely recall was described as 'the ARPANET Unix from UIll'). Noel

1 year, 9 months

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

Apologies for being off-topic > What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Taking it slightly broader (PDP-11 instead of V7), there is a lot of discussion about that on Mike Meuss’ TCP-digest mailing list: https://ftp.ripe.net/rfc/museum/tcp-ip-digest/ There is a 1985 index of available implementations as well ( https://ftp.ripe.net/rfc/museum/tcp-ip-implementations.txt.1 ). It includes the following options for PDP-11 systems: 1.7.5. UNIX 2.9BSD DESCRIPTION: 2.9BSD TCP/IP is an adaptation of Berkeley's original VAX TCP/IP (running under BSD 4.1B UNIX) which in turn is an offshoot of BBN's VAX TCP/IP. 2.9BSD TCP/IP runs on PDP-11/44s and PDP-11/70s. The 2.8 version from SRI was adapted by Bill Croft (formerly at SRI), then Tektronix adapted it for 2.9. Berkeley took over modification of the software and brought it back to SRI where Dan Chernikoff and Greg Satz adapted it for a later release of 2.9. In addition to TCP/IP, UDP, ARP and the raw packet interface is available. ICMP redirects are not supported. User software implementations include Telnet and FTP, plus Berkeley-developed local net protocols, RWHO, RSH, RLOGIN, and RCP. 2.9BSD with TCP/IP support could probably be made to run on smaller PDP-11s although the address space would be very tight and might present problems. 1.7.6. Venix/11 TCP/IP DESCRIPTION: This is based on the "PDP-11/45" implementation available from the MIT Laboratory for Computer Science. It has been ported to a V7 UNIX system, in particular VenturCom's Venix/11 V2.0. As little of the processing as possible takes place in the kernel, to minimize the code space required. It fits comfortably on I&D machines, but is almost hopeless on the smaller machines. The kernel includes a proNET device driver, IP fragment reassembly, IP header processing, local-net header processing, and simple routing. The rest of the IP processing, and all of the UDP and TCP functions, are in user libraries. The psuedo-teletype driver is also in the kernel, and is used by Server TELNET. User programs handle ICMP processing; User and Server TELNET, SMTP, TFTP, Finger, and Discard. There are User programs for Nicname and Hostname. IEN-116 nameservers are used by all programs, and an IEN-116 nameserver is also provided. The TCP used is very simple, not very fast, and lies about windows. No FTP is available, nor is one currently planned. 1.7.8. BBN-V6-UNIX DESCRIPTION: This TCP/IP/ICMP implementation runs as a user process in version 6 UNIX, with modifications obtained from BBN for network access. IP reassembles fragments into datagrams, but has no separate IP user interface. TCP supports user and server Telnet, echo, discard, internet SMTP mail, and FTP. ICMP generates replies to Echo Requests, and sends Source-Quench when reassembly buffers are full. 1. Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with BBN IPC additions. 2. Software - written in C, requiring 25K instruction space, 20K data space. Supports 10 connections (including "listeners"). 3. Unimplemented protocol features: - TCP - Discards out-of-order segments. - IP - Does not handle some options and ICMP messages. 1.7.9. v 3COM-UNET DESCRIPTION: UNET is a communication software package which enables UNIX systems to communicate using TCP/IP protocols. UNET will utilize any physical communications media, from low speed links such as twisted pair RS-232C to high speed coaxial links such as Ethernet. All layers of the UNET package are directly available to the user. The highest layer provides user programs implementing ARPA standard File Transfer Protocol (UFTP), Virtual Terminal Protocol (UVTP), and Mail Transfer Protocols (UMTP). These programs in turn utilize the virtual circuit services of the TCP. The TCP protocol is implemented on top of the IP. Finally, IP can simultaneously interface to multiple local networks. UNET implements 5 of the 7 layers of the International Standards Organization Open Systems Interconnection Reference Model, layers 2 through 6: Link, Network, Transport, Session, and Presentation. Features of TCP 6 not yet implemented are Precedence and Security, End-of-Letter, and Urgent. Feature of IP 4 not yet implemented is Options. Of these, we have 2.9BSD and (a forerunner of) BBN-V6-Unix available on the TUHS Unix Tree. The Venix/11 source and the 3COM source appear lost. These (unfortunately) are the ones that were implemented on top of V7. Also, BBN back-ported the TCP/IP code of BBN VAX-TCP to V7 for their C/70 Unix.

1 year, 9 months

Re: V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by Paul Ruizendaal

> Regarding select, I recall that Dennis implemented it and passed it to > Berkeley*, but maybe not. He certainly had a hand in its design; I > distinctly remember talking to him about it after one of his trips out > west. That is an interesting comment. DMR was on the steering committee for what would become 4.2BSD. I once spoke with Kirk McKusick about the origins of the sockets API and I think he told me that there was a lot of debate in the committee whether descriptor readiness API should be stateful (like Haverty’s await() https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken/awaitr.c ) or stateless (like select). According to Sam Leffler (who I think added select() to 4.1c BSD) the select system call was somewhat modelled after the ADA select statement. I am speculating now, but I would not be surprised if dmr favoured the stateless design and contributed to its design. Paul

1 year, 9 months

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > V7 could mean a modification of net unix What's "net unix" anyway? I know of the Net releases from CSRG, but this much precedes that. What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Noel

1 year, 9 months

Unix V8 Chaosnet, any takers?

by Lars Brinkhoff

Hello, Unix V8 has some code for Chaosnet support. There is a small hobbyist Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes. Is there anyone who would be interested in trying to see if the V8 code is in a workable state, and get it running? Best regards, Lars Brinkhoff

1 year, 9 months

V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by segaloco

Re-subject'd as this part of the conversation diverges. Found the quote that I was thinking of when I said that: https://yarchive.net/comp/bsd.html "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. - Matt G. ------- Original Message ------- On Friday, July 15th, 2022 at 1:51 AM, Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote: > > Message: 6 > > Date: Thu, 14 Jul 2022 17:51:39 +0000 > > From: segaloco segaloco(a)protonmail.com > > > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. > > > I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. > > As I currently understand it, the V8 kernel: > > - is a further development from 32V > - retains the code organisation of the V5..32V versions > - adds virtual memory code from BSD > - adds select() from BSD > > and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) > > In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). > > Paul

1 year, 9 months

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > There is a small hobbyist Chaos network going What encapsulation are they using to transmit CHAOS packets (over the Internet, I assume)? I know there was an IP protocol number assigned for CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of amusing, since in 'Assigned Numbers', the person responsible for 16. is .... me! :-) There was a spec for encapsulating IP in CHAOS, and that actually _was_ implemented at MIT BITD; it was used for a while to get IP traffic to a Unix machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware (very confusing that the same name was applied to hardware, and a protocol suite) ran across to main campus from Tech Square. > From: Grant Taylor > I wonder if there is an opportunity for something that pretends to be > the remote side locally, sends the data via some other > non-latency-sensitive protocol to a counter part where the counter part > pretends to be the near side. Let's think through the details. The near-end 'invisibility box' (let's call it) is going to have to send acks to the original source machine, otherwise that will time out, abort the connection, etc. The originating machine is its own thing, and this behaviour can't be controlled/stopped. (This, BTW, shows a key difference between 'local' and 'across network' modes, a recent topic here; in a situation where two distinct machines are cooperating across a network, the other machine is its own entity, and can't be expected/guaranteed to do anything in particular at all.) In addition, the near-end invisibility box is going to have to keep a copy of each packet, until the destination machine sends an ack to the invisibility box - because if the packet is lost, the invisibility box is going to have to retransmit it. (The original source is not going to - it's already gotten an ack, so as far as it's concerned, that packet is done and dusted.) And the near-end invisibility box is also going to have to have to have a time-out timer, so that when the ack isn't seen, it will know to retransmit the packet. There's no point to _also_ sending the acks on to the originating machine; they won't do anything useful, and might just confuse it. So, let's see now: the near-end invisibility box buffers the packet, looks for an ack, times out when it doesn't see it, re-transmits the packet - that sounds familiar? Oh, right, it's a reliable connection. And presumably there's an invisibility box at the far end too, so the same can happen for any data packets the destination machine sends. The only question is whether, when doing the detailed design, there's any point to having the destination machine's acks sent to the near-end invisibility box - or just use them at the far-end invisibility box. (I.e. create three reliable connections: i) a CHAOS connection originating machine<->near-end invisibility box; ii) {whatever} near-end invisibility ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original destination machine - and glue them together.) That is in some sense simpler than creating an extra-ordinary mechanism to have a 'helper' box in the middle of the connection (to terminate the CHAOS connection from the original machine, and have another CHAOS connection, but with an enhanced time-out mechanism which can cope with larger RTT's, from there to the original destination); and the same in the other direction. The amusing thing is that the CHAOS protocol stack actually already had something very similar to this, BITD. If one were sitting at a machine that only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS connection to that serrver, and it would open an NCP connection to one's intended ultimate destination, and glue the byte streams together. (The ultimate destination was passed as data over the CHAOS connection, when opening it.) Noel

1 year, 9 months

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

> Message: 6 > Date: Thu, 14 Jul 2022 17:51:39 +0000 > From: segaloco <segaloco(a)protonmail.com> > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. As I currently understand it, the V8 kernel: - is a further development from 32V - retains the code organisation of the V5..32V versions - adds virtual memory code from BSD - adds select() from BSD and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). Paul

1 year, 9 months

Re: LSX issues and musing

by Paul Ruizendaal

> If I can get this working, I have a long laundry list of modifications and > experiments that I want to run with LSX, but as it stands, this is where I > am stuck at. Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010: https://en.wikipedia.org/wiki/Electronika_BK (it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a ) The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it: https://github.com/ignusius/bkunix He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11. I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code. Note that LSX only holds one process in core and swaps other processes (NPROC = 3) out to floppy. It reportedly took several hours for the Terak to self-compile LSX from source. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^)

1 year, 9 months

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> From: Gavin Tersteeg > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. > It took a lot of tinkering with the kernel and drivers to make it work > in the way I wanted to You must have made a lot of changes for it to take "a lot of tinkering". Bringing V6 up on the /23 has been done several times, and when I did it, it only took about 2 dozen lines of code in about 2 files. What all did you wind up changing? > From my research, it seems like there were two different UNIX variants > that could run on a system like this. These variants were LSX and > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like > a RK05 and some porting to work on an 11/03, while LSX is designed to > work on exactly the hardware specs that I have on hand. Bringing up MINI-UNIX on the /03 has been done at least twice; once historically (now lost, AFAIK), and again recently: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html I'm not sure what you're basing the "MINI-UNIX seems to require a decent mass-storage device like a RK05" on - it should run as well on whatever you're running LSX on as LSX does. I haven't run LSX myself, but from what I've seen, the only significant difference between the two is that LSX will run with less main memory than MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away with 40KB).That was a significant issue when the LSI-11 was originally released, but these days one has to really work to have a QBUS PDP-11 with less than 56KB. > my EIS-less 11/03 EIS chips can be found on eBait for not much money (I just bought a couple myself), and it's worth investing in one, so on can dispense with the emulator, which takes real memory for which a better use can be found. > The first issue is that the C compiler will randomly spit out a "0: > Missing temp file" when attempting to compile something. This is > annoying, but circumventable by just running the same command over and > over until it works. Schaeffer's Law (from Larry Niven): anything you don't understand might be dangerous. I'd track down why this is happening. Noel

1 year, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS July 2022