TUHS

tuhs@tuhs.org

17 participants
6470 discussions

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Rudi Blom

Whenever I hear UNIX, networking and streams I have to think about this scheme. Still using this, even on HP-UX 11.31 on Itanium rx-servers Cheers, uncle rubl

5 years, 7 months

Re: [TUHS] Running v10

by Norman Wilson

Check out "Setting Up a Research UNIX System" by Norman Wilson. troff sources are in v10. ==== But that assumes you're being given a root image to copy to the disk initially, no? We never made a general-purpose distribution tape; we just made one-off snapshots when someone wanted a copy of the system in the 10/e era. Is there a binary root image in Warren's archive? I forget. Norman Wilson Toronto ON (where the weather feels like NJ these days, dammit)

5 years, 7 months

ARS Technica on UNIX @ 50

by Clem Cole

https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainfra…

5 years, 7 months

systime

by Steve Simon

wow, systime. i went for a student placement there but didnt get it - i guess my long hair (then) didn't fit as the interview seemed good. i had a mate who was working late on the day the combined uk police and CIA (it was said) arrived to shut them down, and tell them they ARE being taken over by CDC. the crime was selling systime re-badged vaxes to the ussr at the height of the cold war. seem odd now that they thought they could get away with it. exciting times. -Steve

5 years, 7 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Doug McIlroy

> Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: > >> >>> How long was research running on a PDP-11 and when did they move to a VAX? >> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. >> >> Doug > > So, what's the story on why the London/Reiser port didn't get adapted > back by Research, and they ended up starting from 4.1 BSD? > > Thanks, > > Arnold Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did. Doug

5 years, 7 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Doug McIlroy

> How long was research running on a PDP-11 and when did they move to a VAX? London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. Doug

5 years, 7 months

Lions Commentary on Unix

by Clem Cole

Gentlefolk, Does anyone have an original copy of the Lions text. All I have is the new printed version and my nth generation photocopy from 1975. There is another 50th event occurring a few weeks that would love to be able to borrow a copy for an artifact display. Reply to me off-list if you can help. Clem

5 years, 8 months

DEC's MIPS product (was If not Linux, then what?)

by Paul Winalski

On 8/28/19, Clem Cole <clemc(a)ccc.com> wrote: > > So, I think the MIPS product was a holding pattern while DEC got it's > strategy together. Alpha would really show up until later (I would leave > LCC and go to DEC to be apart if that). Also note Alpha was brought > up/debugged on Ultrix and of course, Prism sort of had Ultrix on it. But > I think using the MIPS chip keep them in the game, when Vax was dying and > RISC was the word on the street. I was in DEC's compiler development team at the time, working on the new GEM common back end, and this matches my recollection. The original plan was for GEM to be the successor to the VAX Code Generator (VCG, the common back end used by DEC's PL/I, Ada, C/C++ and a few other compilers on VAX/VMS) and its first target was the VMS personality module Prism's OS, Mica. Prism was close to delivering silicon when it was cancelled in favor of Alpha. DEC's MIPS-based products were done as a stopgap until Alpha was ready. The GEM group implemented a MIPS code generator. I don't recall whether we actually shipped any GEM-based products on the MIPS/Ultrix platform. GEM focused on Alpha (on VMS, Unix, and Windows host and target platforms) shortly thereafter. -Paul W.

5 years, 8 months

dmr streams & networking [was: Re: If not Linux, then what?]

by Paul Ruizendaal

> I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. That's what I know but you were > there, I was not. I'm pretty confused because what Dennis said to me > was that he did not think streams would work for networking, he thought > they made sense for a stream but not for a networking connection because > that had multiple connections coming up through a stream. There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views. [1] The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed. [2] However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3A… The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph. If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd...(a)dutoit.xn--uucp-y96a to make it fold out. For ease of reference, I’m including the message text below. <quote> Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie </quote> Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking. Paul

5 years, 8 months

/dev/null

by Norman Wilson

John Steinhart: Just curious - am doing a cross-country road trip with my kid and saw a Wisconsin dev null license plate. Didn't get a look at the driver. ===== It's in ken/mem.c in Fourth Edition, dmr/mem.c in Fifth and Sixth. Norman (no sheds) Wilson Toronto ON

5 years, 8 months

Jump to page:

2025

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