> 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
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.
> 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
> 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
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
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
> 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
> 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
> 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 :^)
> 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
