TUHS

tuhs@tuhs.org

47 participants
6503 discussions

Start a nNew thread

Bill Shannon RIP

by Matt Day

David Rosenthal has written a wonderful memorial of Bill Shannon: https://blog.dshr.org/2020/06/bill-shannon-rip.html

4 years, 10 months

Re: [TUHS] VFS prior to 1984

by Paul Ruizendaal

Date: Wed, 24 Jun 2020 14:31:34 -0400 (EDT) From: norman(a)oclsc.org (Norman Wilson) > Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison. > Norman Wilson Toronto ON I am still digesting all the inputs (thanks, all!) The above post made me realise that the delineation of what is a FSS/VFS or not, is not so easy. I did a little bit of reading, and the concept of an ACP arrived with RSX11D in May 1973, but only matured in RSX11M in November 1974. As I understand it, originally in RSX11 file system code was closely tied to the low-level device driver for each device. ACP’s separated the file system code from the device driver itself, and became separate processes. In essence there were two switches: one switch into abstract devices, implemented in ACP code and one kernel switch to deal with hardware interfacing. The first is indeed like a file system switch (although still tied to specific devices). Looking at this stuff made me realise that my retro machine of choice (the TI990) went through a similar evolution. In the early seventies it had a sort of abstract device switch that linked to individual ‘device service routines’ (drivers). Initially, these modelled batch oriented ‘logical units’ that tied to files at the job control level. Later (late 70’s), the ‘open’ command would carry a file name and the file system was delegated to the device service routine. Still later (say 1983) this was used for networked disks. As several people have observed in this topic, indeed there appears to be a close relationship between a device switch and a file system switch.

4 years, 10 months

Okistations and OKIX?

by Aaron J. Grier

Anybody on the list know much about the provenance of SVr4 and OKIX for the Okistation 7300 model 30? http://museum.ipsj.or.jp/en/computer/work/0029.html indicates that OKIX came later on the model 75, but many years ago as a staff programmer at Oregon Graduate Institute, a surplus 7300/30 followed me home, but the sysadmins referred to it as OKIX. if anybody's interested in the hardware to do some spelunking, email me off-list. -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com "The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay." -- Tony Hoare

4 years, 10 months

Mike Hawley has died

by Deborah Scherrer

Some very sad news: http://news.mit.edu/2020/michael-hawley-former-professor-media-arts-science…

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Rob Gingell > RSEXEC (Resource Sharing EXEC) done on TENEX earlier in the 1970s. That was associated with the National Software Works project: https://apps.dtic.mil/dtic/tr/fulltext/u2/a132320.pdf I think? (It's been four decades since I looked at NSW, so I don't recall much about it.) Neither was TENEX-specific; e.g. there were Multics implementations of RSEXEC and NSW. Noel

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Richard Salz > A web search for "its mldev" finds several things (mostly by Lars > Brinkhoff it seems) Yeah, other than the source: https://github.com/PDP-10/its/blob/master/src/sysen2/mldev.106 there's not a lot on it. That's typical of a lot of the innovative work done at the AI Lab, LCS, etc; they built some extraordinary tools, but to them they were just tools they used to work on their research, their _real_ work. So why bother to write that stuff up? So people who actually used them remember them, but other than that... Welcome to tomorrow, where everything gets re-invented, because everyone is too busy to waste time learning about the past. Noel

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: "Greg A. Woods" > as Organick said in his 1972 book A word of warning: i) Organick describes Multics as it was planned, not as it was actually implemented; and ii) then it changed considerably during its service life. Examples of each: i) there was one linkage segment per processs, not per segment (linkage info was copied across into the shared linkage segment when a segment was dynamically added to a process' address space); ii) the New Storage System. The basic concepts (single level store, dynamic linking etc) are correct in Organick, but be wary of anything past that. Not his fault, of course; things just changed. > As far as I can remember Multics didn't really have the concept of a > "mount point". In the original design, no. In 1973-75, with the New Storage System: https://multicians.org/nss.html mountable volumes were added (see MTB 229, "Use of Demountable Logical Volumes", linked from the page above). It was released to customers in June, 1976. Noel

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by norman＠oclsc.org

Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison. Norman Wilson Toronto ON

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Anthony Martin > wherein they state the following: > A virtual file system, from the viewpoint of application programs on a > computer, models the file system functions of other computers. This is > done in the same way as with virtual terminals, a virtual file system > consists of a UPP having virtual files (VF), and a UCP which executes > virtual file system protocols. > I'd be interested if you find anything earlier. MLDEV on ITS would, I think, fit under that description. I don't know if there's a paper on it; it's mid-70's. Noel

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > Ioctl: the Swiss Army knife of system calls. I thought it was a neat > idea when it arrived (much better then those primitive stty/gtty calls) > but now... Like they say, when the only tool you have is a hammer... Better syntax than stty/gtty, maybe but I'm not sure the semantics are that much better. The problem is that, especially with devices, what the I/O commands do is so widely varied that it's hard to fit them all under a unified umbrella. Maybe some (e.g. asynchronous I/O), but not all. Noel

4 years, 11 months

Unix 8th / 9th edition IPC paper

by Paul Ruizendaal

There is an interesting paper that Dennis Ritchie and Dave Presotto wrote, “Interprocess Communication in the Ninth Edition Unix System” (https://www.bell-labs.com/usr/dmr/www/ipcpaper.html <https://www.bell-labs.com/usr/dmr/www/ipcpaper.html>). This appears to be an update of a paper that they wrote in 1985, “Interprocess Communication in the Eighth Edition Unix System”. This earlier paper is hard to find. Anybody on this list who has it on hand?

4 years, 11 months

Re: [TUHS] VFS prior to 1984

by Norman Wilson

Rob Pike: For my taste, the various Unix file system switches that I've seen are too firmly tied to the idea of blocks and disks and all that, making them less flexible than they should have been. That's why the Plan 9 version is about names and byte streams, to make it as general as possible. ===== The only file-system switch I know well is that in the later Research systems. It has nothing to do with disks or blocks. It is about names and inodes: turn name to struct inode, read arbitrary chunk of data, write arbitrary chunk of data, create file, unlink file, abominable ill-defined system call that just wouldn't die erm I mean ioctl, and so on. It was certainly a cheap hack (as its author cheerfully admitted) but it really was about I/O operations, not about simulating disks. That's why it so easily supported /proc (the one that was just about processes, not the misnamed Linux one that is really about all things in the kernel so you don't need /dev/kmem). I don't know a lot about later VFSes like those in SunOS or Linux or the BSDs. Blockiness might well have crept in in support of memory-mapped I/O or in collaboration with the buffer-cache implementation. The Research version was never used directly to support different on-disk file system formats (we did a different pjw cheap hack for the one case that mattered in the kernel, and used the idea later developed more by FUSE for other cases because speed didn't matter). Norman Wilson Toronto ON

4 years, 11 months

Re: [TUHS] Fwd: Origins and life of the pg pager

by jnc＠mercury.lcs.mit.edu

> From: Michael Siegel > there's no need to write out "less" every time. You can just alias that > to "pg" without causing any harm and save two letters, which is an > improvement for a task that is performed manually rather often. It always surpised me that there wasn't more of this - abbreviating the names of the most-used commands, to minimize typing - or more specifically, run-length encoding them based on how frequently they were used, with the most-used ones given the shortest names. The MIT-DSSR PWB1 system had a pager called just 'p' (source here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/p.c if anyone wants to see it; the man page is dated Apr/77); and 'ls' was tweaked to recognize the command name 'l' as an alias for 'ls -ls'. Of course, aliases didn't exist in the shell back then, which was why the command had to be coded to recognize the short form, and act differently. (And /bin/l was linked to /bin/ls.) 'l' and 'p' are _still_ aliased in my shell,to this day! > I hope it's okay that I chose to reply just to the list address and take > all the other addresses out. 'That's not a bug, that's a feature!' I always delete other addresses when replying to a list, unless I think someone might not be subscribed to that list. Noel

4 years, 11 months

Jon Bentley's DFORMAT preprocessor now available

by Arnold Robbins

Hello All. I have reconstituted Jon Bentley's DFORMAT preprocessor (troff and awk source) and made it available on GitHub. See https://github.com/arnoldrobbins/dformat. This is an awk program that reads a description of data layouts, such as registers or network packets, and generates PIC descriptions. A Makefile generates PDF from the dformat.ms file using GNU troff. Jon Bentley was helpful in the final stages, including contributing his original files. Enjoy! Arnold Robbins

4 years, 11 months

Dennis's list thesis is found

by Richard Salz

https://computerhistory.org/blog/discovering-dennis-ritchies-lost-dissertat…

4 years, 11 months

2.9BSD-Seismo

by Warner Losh

So in BSD family tree, there's a 2.9BSD-Seismo and a 2.9.1BSD listed. Yet I can't seem to find them in the TUHS archive. There is a 2.9-Patch directory dated 1985 the same as the date that's found in the family tree. Is that the Seismo version? And Kirk's archive has a 2.9pucc directory, which appears appears to be from Purdue dated1987. How does this relate? Thanks for any help you can provide Warner

4 years, 11 months

updated: loop networks at Bell Labs

by Paul Ruizendaal

With some further reading and research (and the kind help of Heinz Lycklama and Jon Steinart) I’ve found that my understanding of early loop networks at Bell Labs confused several different systems. As far as I can currently tell there were at least 4 different loop networks developed around 1970 at Murray Hill. 1. The first one is the “Newhall Loop” (paper published in 1969). This loop used twisted pair cabling, ran at about 3Mhz and used variable sized messages. It seems to have used some sort of token to coordinate between hosts. This might have been the network that Ken Thompson recalled as having been in operation when he arrived at the labs in 1966. 2. The second one appears to have been the “Pierce Loop”, as described in 3 BSTJ papers submitted in 1970/71. This one was coax based, used T1 compatible frames and was used to connect H516 computers with various bits of equipment. It seems to have had a very short life span. Part of my confusion was that the term Pierce Loop also appears to have been used in a generic sense to denote loop networks with fixed-sized frames. 3. The third one is the “Weller Loop” (paper published in 1971). This loop used coax cabling, ran at 3.3Mhz and used fixed 35 bit frames/cells. Each cell carried one address byte and two data bytes. One participant on the loop was the controller and effectively polled the other stations. In its 1971 form it appears to have been for the H516’s only and was referred to as a “Serial I/O bus”. This is what Jon Steinhart was talking about. The Weller loop was later redesigned (memo written in 1973) to interface with PDP-11’s as well. Heinz Lycklama used this loop in 1974 to connect several systems running (rump) Unix - see his paper about peripheral Unix here: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… <https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…> This Serial I/O bus remained in use for several years at least. 4. The fourth and best known one is the “Spider Loop” (memo published in 1974, but operational from 1972). Twisted pair cabling, using T1 compatible frames. In use until about 1978. Main uses appear to have been the ‘nfs’ file store and the ‘npr’ remote printing service. My conclusion from all that is that in 1974 Unix had access to two networks, Spider and the Serial I/O bus. For both, first experiments would have been in 1973. It is hard to be sure which one came first. If I had to venture a guess today, I’d say that Spider connected to Unix several months before the Weller loop (even though the 1st generation Weller loop preceded Spider). Maybe the conclusion is that both happened more or less in parallel: Weller was also one of the designers of the Spider hardware.

4 years, 11 months

Interesting problem

by Gregg Levine

Hello! I normally download items from the Society FTP site rather than from the archival area on the website. And my clients kept getting bounced, claiming that I should stop trying to connect frequently. Oddly enough that was not the case a while ago. Was the archive recently updated regarding hosting software? On Windows it was FileZilla, and spun down to one rather than eight or ten. And on the WSL SLES12 SP3 arrangement it was ncftp. Now downloading the reports to go along with the one Paul made available from the location is not important for today, I can wait until tomorrow or the next day. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

4 years, 11 months

Re: [TUHS] Origins and life of the pg pager

by Norman Wilson

Rob Pike: Yeah, p is all we need. I think it originated with td at UofT. I might have brought it with me to Bell Labs, or recreated it. Probably the former. ==== The former, I think. The source code in V10 is very similar to that you left behind at Caltech (where I first encountered p). Most differences have to do with using opendir and readdir rather than reading raw directories in the SPname code. A further clue is that, even in V10, p.c begins /*%cc p.c pad.o spname.o */ The tool that looked for such lines to tell it how to compile things (I forget its name; was it comp?) doesn't seem to have survived in the archival backup I have from Caltech HEP, but I'm quite sure it came from U of T as well. Norman Wilson Toronto ON

4 years, 11 months

Re: [TUHS] Origins and life of the pg pager

by Doug McIlroy

> less(1) was actually an improvement Hmm. Less is my favorite whipping boy for featuritis. % less --help |wc 242 1331 12202 I am very happy with p. Doug

4 years, 11 months

v7 K&R C

by Adam Thornton

The C in v7 is, canonically, the language described in K&R, right? I must be doing something dumb. I am getting Webb Miller’s “s” editor built there, and I am down to one function. /* chop_arg - chop a function's argument to a maximum length */ static chop_arg(fcn, arg, maxlen) int (*fcn)(); int maxlen; char *arg; { char save; save = arg[maxlen]; arg[maxlen] = '\0'; fcn(arg); arg[maxlen] = save; } This doesn’t like the function pointer. $ cc -c choparg.c choparg.c:11: Call of non-function So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7? Adam

4 years, 11 months

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

by jnc＠mercury.lcs.mit.edu

> From: Diomidis Spinellis > From the 2.11 BSD sources I understand that the PDP-11/70 MMU address > and data registers, KDSA and KDSD, start at 0172360 and 0172320 > respectively ... Expressed as 16-bit addreses, on a PDP-11 with mapping disabled, yes. > I checked this by looking at /dev/mem. I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS; on a /70 it's a separate 22-bit address bus). In the /70 memory address space, the 'I/O page' (which is where the PxR's live) is at the top end of it, i.e. the registers are at 017772360 (KDSAR0), etc. > What am I missing? PDP-11's have a plethora of address spaces, of different sizes. You need to always be aware of which one you're working in. > My goal is to access from the console the kernel's u area. According to > mem(4) and the symbols in /unix, this should be at address 0140000. In the kernel virtual address space, yes. > Indeed, accessing it through /dev/kmem I get the expected results for > e.g. u_comm and u_uid. Because /dev/kmem gives access to kernel address space for the _current_ process. > I have been unable to find it in the machine's physical memory By far and away the easiest thing, for the _current_ process, is to use /dev/kmem, which automagally applies the correct mapping. For other processes, if the process is swapped in, there's some field in the proc structure which says where in physical memory it us. IIRC, the user struct and the kernel stack are stored in the very bottom of that. (This article: http://gunkies.org/wiki/Unix_V6_dump_analysis#Memory_layouts goes into some detail for V6. Not sure how different 2.11 is; I know it uses one block of kernel address space to map in code overlays, but I don't know all the details of how it works.) Anyway, using that, one could read the user area in /dev/mem, at the appropriate location. For swapped-out processes, a similar algorithm applies, but you'll have to look in the swap device (obviously). Noel

4 years, 11 months

Re: [TUHS] v7 K&R C [really lexers]

by Doug McIlroy

Interesting. My "speak" program had a trivial lexer that recognized literal tokens, many of which were prefixes of others, by maximum-munch binary search in a list of 1600 entries. Entries gave token+translation+rewrite. The whole thing fit in 15K. Many years later I wrote a regex recognizer that special-cased alternations of lots of literals. I believe Gnu's regex.c does that, too. (My regex also supported conjunction and negation-- legitimate regular-language operations--implemented by continuation-passing to avoid huge finite-state machines.) We have here a case of imperfect communication in 1127. Had I been conscious of the lex-explosion problem, I might have thought of speak and put support for speak-like tables into lex. As it happened, I only used yacc/lex once, quite successfully, for a small domain-specific language. Doug Steve Johnson wrote: I also gave up on lex for parsing fairly early. The problem was reserved words. These looked like identifiers, but the state machine to pick out a couple of dozen reserved words out of all identifiers was too big for the PDP-11. When I wrote spell, I ran into the same problem. I had some rules that wanted to convert plurals to singular forms that would be found in the dictionary. Writing a rule to recognize .*ies and convert the "ies" to "y" blew out the memory after only a handful of patterns. My solution was to pick up words and reverse them before passing them through lex, so I looked for the pattern "sei.*", converted it to "y" and then reversed the word again. As it turned out, I only owned spell for a few weeks because Doug and others grabbed it and ran with it.

4 years, 11 months

Accessing the PDP-11/70 MMU registers and the kernel's u area

by Diomidis Spinellis

From the 2.11 BSD sources I understand that the PDP-11/70 MMU address and data registers, KDSA and KDSD, start at 0172360 and 0172320 respectively [1]. Yet, when I read the register contents I don't get what I would expect to see: increasing by 0200 memory values for KDSA and the same constant value for KDSD [2]. I checked this by looking at /dev/mem. # od -o /dev/mem 0172360 | head -1 0172360 000002 000016 001403 012700 000400 000402 012700 000200 # od /dev/mem 0172320 | head -1 0172320 101016 005064 000026 005067 175456 016467 000006 175430 I get the same results when I examine the memory through SIMH: sim> examine 172360 172360: 000002 sim> examine 172362 172362: 000016 sim> examine 172364 172364: 001403 sim> examine 172320 172320: 101016 sim> examine 172322 172322: 005064 The MMU kernel instruction registers, KISA and KISD, contain similarly nonsensical values as do the registers located at a different memory location (077320, 0772360) indicated in another source [3]. What am I missing? My goal is to access from the console the kernel's u area. According to mem(4) and the symbols in /unix, this should be at address 0140000. Indeed, accessing it through /dev/kmem I get the expected results for e.g. u_comm and u_uid. However, I have been unable to find it in the machine's physical memory, hence my question regarding the MMU's operation. [1] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L346 [2] https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L247 [3] https://gunkies.org/wiki/PDP-11_Memory_Management Diomidis

4 years, 11 months

non-blocking IO

by Paul Ruizendaal

This time looking into non-blocking file access. I realise that the term has wider application, but right now my scope is “communication files” (tty’s, pipes, network connections). As far as I can tell, prior to 1979 non-blocking access did not appear in the Spider lineage, nor did it appear in the NCP Unix lineage. First appearance of non-blocking behaviour seems to have been with Chesson’s multiplexed files where it is marked experimental (an experiment within an experiment, so to say) in 1979. The first appearance resembling the modern form appears to have been with SysIII in 1980, where open() gains a O_NDELAY flag and appears to have had two uses: (i) when used on TTY devices it makes open() return without waiting for a carrier signal (and subsequent read() / write() calls on the descriptor return with 0, until the carrier/data is there); and (ii) on pipes and fifo’s, read() and write() will not block on an empty/full pipe, but return 0 instead. This behaviour seems to have continued into SysVR1, I’m not sure when EAGAIN came into use as a return value for this use case in the SysV lineage. Maybe with SysVR3 networking? In the Research lineage, the above SysIII approach does not seem to exist, although the V8 manual page for open() says under BUGS "It should be possible [...] to optionally call open without the possibility of hanging waiting for carrier on communication lines.” In the same location for V10 it reads "It should be possible to call open without waiting for carrier on communication lines.” The July 1981 design proposals for 4.2BSD note that SysIII non-blocking files are a useful feature and should be included in the new system. In Jan/Feb 1982 this appears to be coded up, although not all affected files are under SCCS tracking at that point in time. Non-blocking behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is returned instead of 0 when progress is not possible. The non-blocking behaviour is extended beyond TTY’s and pipes to sockets, with additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not the same error number as EGAIN. It would seem that the differences between the BSD and SysV lineages in this area persisted until around 2000 or so. Is that a fair summary? - - - I’m not quite sure why the Research lineage did not include non-blocking behaviour, especially in view of the man page comments. Maybe it was seen as against the Unix philosophy, with select() offering sufficient mechanism to avoid blocking (with open() the hard corner case)? In the SysIII code base, the FNDELAY flag is stored on the file pointer (i.e. with struct file). This has the effect that the flag is shared between processes using the same pointer, but can be changed in one process (using fcntl) without the knowledge of others. It seems more logical to me to have made it a per-process flag (i.e. with struct user) instead. In this aspect the SysIII semantics carry through to today’s Unix/Linux. Was this semantic a deliberate design choice, or simply an overlooked complication?

4 years, 11 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