TUHS

tuhs@tuhs.org

6 participants
6532 discussions

MASSCOMP MC-500 Guide to Writing a Unix Device Driver

by Warner Losh

Greetings, I'm trying to find the predecessor to "Writing a UNIX Device Driver, J. Egan & T. Teixeira, 1st ed, 1988". In the preface, it says: "This book is based on a MASSCOMP manual, Guide to Writing a Unix Device Driver. The first version that MASSCOMP published as part of the documentation set for the MC-500 was based on preliminary drafts prepared for MASSCOMP by Cliff Cary and Tom Albough of Creare R&D." I checked bit keepers and found nothing. I was wondering if people on this list know of this manual, have a copy, etc. In general, I'm looking for pre-SysV driver manuals. I can find all kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well), but nothing for System III or V7 unix. There were a lot of early systems that were based on ports of V7 to different architectures that were then updated to System III or System V (at least according to the big chart of unix history and some wikipedia entries, which may be just repeating marketing schlock and not reflect actual reality). As part of a talk I'm putting together on the 40th anniversary of V7, I wanted to have a bit of history for things we still have in unix today (like strategy) and things that successors to unix have added or left behind (like the packet mux in V7 that was tossed aside for either STREAMS or netinet from BSD, though packet muxing to userland is back with DPDK). Warner

6 years, 2 months

A question about ls(1)

by Anthony Martin

>From at least V2 to V6, the ls(1) command would not show directory entries whose names began with a '.' unless the -a flag was supplied. This was changed in V7: only the directory entries for "." and ".." would be skipped by default. All further versions of Research Unix retain the convention of V7 and Plan 9 ultimately made it unnecessary. However, BSD and its descendants did not follow suit. Instead, they continued behaving like V6 with an additional -A flag to emulate V7. Was the initial behavior intentional or just a matter of expediency? Who made the change and what was their motivation? Was it a reaction to the intentional hiding of what came to be known as "dot files"? Thanks, Anthony

6 years, 2 months

Re: [TUHS] OT: Need help getting old 9 track tapes read

by jnc＠mercury.lcs.mit.edu

> From: Arnold Skeeve > If you have information, PLEASE send it to me so that I can relay it > to Scott. IMO, only one choice: Chuck Guzis (cclist(a)sydex.com) he's very active in the vintage computer community, and reads old media professionally. I've used him (to recover those backup tapes of the MIT PWB1 system), which was rather tricky (bad mold; he had to build a special tool to remove it), and I was incredibly happy. Very reasonable price too - although he may have given me a special 'collector' rate.. :-) Noel

6 years, 2 months

v8 networking and streams (was: a question about ls)

by Paul Ruizendaal

> There was a hacky implementation of TCP/IP which we didn't really use: > 4.Y BSD (I don't know the value of Y) protocol code, wrapped up to > work as stream modules* and shoehorned in, with a custom API quite > different from the BSD one. The work was done by a summer student, > Robert T. Morris, who later became rather famous for a smaller but > rather more troublesome bit of network code. Our production network > was Datakit, which was also implemented as stream devices and modules > (it was the network whose use inspired the stream design, in fact). I’d love to hear more about that. So far, the only information I have found about (lowercase) streams and networking - as used at the labs - is the v8 source code and a 1984 message from dmr on a mailing list. The (lower level) v8 networking concepts appear to carry through to v10 and Plan9. It is my impression that the unix/datakit tradition essentially views a network connection as a special kind of device, whereas the unix/arpanet tradition essentially views a network connection as a special kind of pipe. In both cases this would seem to have been an accidental choice driven by convenience in early implementations (respectively the Spider network drivers and NCP Unix from the UoI). However, that is an impression formed 35+ years after the fact and the contemporary view may have been very different. Paul

6 years, 2 months

Re: [TUHS] A question about ls(1)

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson > Quite a while ago, someone asked how multiplexing was handled in the > stream world. I meant to write a reply but never did. In a sentence, > by a paired device driver and stream module. If someone wants more > details I'll be glad to write more about that. Please. Thanks! Noel

6 years, 2 months

Re: [TUHS] A question about ls(1)

by norman＠oclsc.org

On Sat, Apr 27, 2019 at 09:38:27AM -0600, Warner Losh wrote: But I find this interesting, since the 8th edition was based on BSD 4.1c I thought.... `Based on' is an overstatement, except in the kernel. The system described in the 8th Edition manual (as noted in the past, there was only sort of a real V8 release) had a kernel that started as 4.1x BSD. I'm not sure of the value of x. It had the Joy/Babaolgu paging code and the complicated changes to signals, and a lot of the gratuitous asms, but not a trace of the BSD networking API. Neither was the BSD FFS present. Local additions included Dennis's original stream implementation, which completely replaced the old tty code and rewrote the drivers for serial-port devices. The tty driver (responsible for cooked mode, interrupt and quit signals, and the like) was a stream module. The BSD-style `new tty line discipline' was a separate module, for the few people who couldn't live without csh. Tom Killian's original version of /proc and Peter Weinberger's original network file system (neta) client were there. These were accessed through a file system switch, also Peter's work. Instead of FFS, Peter made a simple speedup to the V7 file system: adding 64 to the minor device number meant the file system used 4KiB blocks. The unused space at the end of the now-4KiB superblock was a bitmap of free blocks, allowing somewhat-smarter block allocation. There was a hacky implementation of TCP/IP which we didn't really use: 4.Y BSD (I don't know the value of Y) protocol code, wrapped up to work as stream modules* and shoehorned in, with a custom API quite different from the BSD one. The work was done by a summer student, Robert T. Morris, who later became rather famous for a smaller but rather more troublesome bit of network code. Our production network was Datakit, which was also implemented as stream devices and modules (it was the network whose use inspired the stream design, in fact). [* Quite a while ago, someone asked how multiplexing was handled in the stream world. I meant to write a reply but never did. In a sentence, by a paired device driver and stream module. If someone wants more details I'll be glad to write more about that.] That's just the kernel, though. The user-mode world was largely descended from V7 rather than from BSD. Most people used sh, which had been augmented a bit by Rob Pike (perhaps et al) to add functions and a simple external history mechanism (Tom Duff's idea, I think). wc had no uucp-dependent flags, and cat had no flags at all. ls did sniff at whether standard output was a tty and put things in columns. Things mutated further as time went on, further diverging from and discarding aspects of the BSD origin. (I can take credit or blame for a lot of that, though not all.) But that happened later, and is reflected in the 9th and especially 10th editions of the manual. Norman Wilson Toronto ON

6 years, 2 months

Historical events/conferences in 2019?

by reed＠reedmedia.net

I never heard about any history/anniversary track at Usenix in summer in Renton, Washington. It will be an unofficial side event if anything. I have no details. I heard about the two Vintage Computer Festival events but probably too soon for me. Does anyone know of any other events with a focus on the Unix anniversary?

6 years, 2 months

[ANN] Utilities for 4.3BSD: set post-Y2K date, etc.

by Dario Niedermann

Hi! I am releasing 'datekit-1.0' for 4.3BSD-Reno: a couple of free utilities for setting post-Y2K date and time, plus timezone and DST. Here's a brief outtake from the README, detailing the archive contents: [...] date.c the 4.3BSD-Quasijarus `date' program, modified to optionally accept 4-digit years, and default to post-2000 for 2-digit years [...] It can also: + set Daylight Saving Time: option -d [...] + set a time zone: -t minutes-West-of-Greenwich. Negative values for East. rdate.c the `rdate' program ported from OpenBSD 2.0: it synchronizes your machine's clock to that of a remote host, by connecting to the host's "time" service. [...] Man page for `rdate' and a Makefile for both programs are provided. All of the above made and tested in 4.3BSD-Reno, on an emulated VAX-11/780. Archive for download at: <gopher://darioniedermann.it/1/Computing/sw/datekit> -- Dario Niedermann. Also on the Internet at: gopher://darioniedermann.it/ <> https://www.darioniedermann.it/

6 years, 2 months

New project to recreate the B compiler for the PDP-11

by Robert Swierczek

I just started a project to recreate the B compiler for the PDP-11 as authentically as possible, given the few fragments that remain and some educated guesswork. It should be fun (for various definitions of fun). Here is the repository https://github.com/rswier/pdp11-B I have borrowed some tools from Warren's https://github.com/DoctorWkt/unix-jun72 I have made a good start at reverse engineering the B run time library in /usr/lib/libb.a. I have tried to make the source match the same style as the earliest C library found on the last1120c-bits tape. The remaining functions in libb.a include printf and printn which appear to be written in B. This should provide more clues needed to create the compiler. I am also tackling the dis-assembly of the threaded code interpreter /usr/lib/bilib.a (which at the moment is a big mess on my hard-drive) Later steps will include creating the B compiler itself by carefully pruning down the last1120c C compiler. The fun here will be to boot-strap the B compiler without help from any existing modern compilers. I think TMG will come into play to make that happen. All are welcome to contribute! Rob

6 years, 2 months

VCF East in May

by Warren Toomey

Hi all, just to let you know that VCF East in May has some Unix anniversary events. bwk will be interviewing ken as one of the keynotes. Wish I could be there! Details at: http://vcfed.org/wp/festivals/vintage-computer-festival-east/ Cheers, Warren

6 years, 2 months

Joe Condon [ long, slightly off-topic post ]

by Jon Steinhart

So as part of my attempt to remember the names of the folks with who I worked I just read Joe's wikipedia page which doesn't seem accurate to me. If this is too off topic let me know. The page says that Joe "was exposed to UNIX on the Honeywell 516 machines in the early 1970s." This seems wrong to me. We did have a 516, but it ran an experimental virtual memory system called 516-TSS. I lived on this system and still have some of the octal instruction opcodes burned into my brain-ROM. I seem to recall that the department got a PDP-11/40 that ran UNIX version 3 in maybe the summer of 1972 which I used for writing up the documentation for my project. The page also says that "Condon and Ken Thompson promoted the use of the C programming language for AT&T’s switching system control programs. Condon acquired a small AT&T PBX (telephone switch) that handled about 50 phones; he made the necessary hardware changes and Thompson wrote the necessary software programs. The PBX code rewrite in C was a success and hastened the adoption of C for all switching system software within AT&T." This also doesn't match my recollection. One of the big projects in the department was what I think was called SS1 for Slave Switch 1, which was an all-digital telephone exchange. It replaced some other monstrosity whose details I can't recall except that Joe and Dave Weller signed the appropriate paperwork allowing me to take a good portion of it home when it was decommissioned giving me a huge stock of Augat wirewrap boards and 7400-series parts. The SS1 was originally going to use LSI-11s but the stupid way in which DEC implemented the DRAM refresh made that impossible. I think that the final thing used a couple of PDP-10s. As part of being all-digital it used the digital filter work by Jim Kaiser and Hal Alles. I do remember going into Carl Christensen's office to ask him a question and found him staring at a huge C listing; it turns out that a bug in the code had caused SS1 to send KP pulses without their corresponding ST pulses with the result that every single keypulse sender in the Berkeley Heights telephone exchange was taken off line and needed to be manually reset to restore long distance service. They were not happy. Anyway, unless there was something that happened later after I was gone, I'm thinking that the wikipedia page is incorrect and that this PBX was built, not acquired. It was, as far as I know, the first use of C to control machinery. It's actually because of this machine that I'm trying to track down the name of some folks from down at the end of the hall. I have strong memories of the Bell System exhibit at the '64 World's Fair, especially the booth where one could go and talk and they had bar graphs on a monitor showing the spectrum of your speech and could mess with it. Many years later, while waiting for some deck of cards to finish loading, I poked my head into the lab down the hall to see what they were doing in there, and noticed polaroid photos of that exhibit featuring the guys in the lab. Once they stopped telling stories from the World's Fair, they taught me a lesson about systems engineering that opened my eyes. They were developing a circuit that replaced the pound of iron hybrid transformers that were on every telephone line with a small toroid and an op-amp. Their circuit would sense when the iron was getting close to saturation and run current through an additional winding to keep it in the linear region. While that circuit cost a lot more than a hybrid transformer, it paid for itself by reducing the amount of concrete needed to build telephone exchanges. Would love to know who these guys were which is why an org chart would help. And maybe someone out there like Ken can help me out with the accurate history. Jon

6 years, 2 months

Re: [TUHS] 516-TSS, was re: Joe Condon

by jnc＠mercury.lcs.mit.edu

> From: Grant Taylor > What OS did the 516 / TIP run? Google is your friend. A Web search for 'ARPANET IMP software' will answer your question. Noel

6 years, 2 months

Re: [TUHS] UNIX System Internals

by jnc＠mercury.lcs.mit.edu

> From: Jon Steinhart > OK, well, how do we make this happen? Is it bound or un-bound, and if the former, are you OK with unbinding it? If the former, and 'no', we either need to rope in someone with one of those special rigs for scanning books, or do it by hand. If not, I have an auto-feed scanner, and volunteer to do it. How large are the pages? Noel

6 years, 2 months

UNIX System Internals

by Jon Steinhart

Don't know if this is of interest to anybody out there, but I was just looking for something else in the basement and came across two notebooks that look like a UNIX System Internals course. Appears to cover version 6, version 7, PWB, 32V, System III, and System V. Has the Western Electric seal of disapproval on the front. Jon

6 years, 2 months

UNIX System Internals

by Norman Wilson

I'd love to see this stuff. Were I not so far away I'd offer to scan them for you, but it shouldn't be hard to find someone who can in the Bay Area. (Attention USENIX Association, I approve use of my membership dues to support this!) Norman Wilson Toronto ON

6 years, 2 months

looking for HOSTS.TXT parsers and how is /dev/net/HOSTNAME enabled?

by reed＠reedmedia.net

This email is two parts. I am researching 1970's symbolic name to network address mapping routines. 1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since this is Unix list, for Unix is fine :) RFC 597 (12 December 1973) says a hostname list will be maintained at the NIC with the location to be announced. (Interestingly NIC as in FEINLER@NIC is probably a nickname as it is not listed in the host status list. I am guessing it is a nickname for SRI-ARC or OFFICE-1.) RFC 606 (December 1973) says there are different hosts lists, but "now" there is "the official list of host names". It proposed that it should be maintained online in machine-readable form. It proposes a format and suggested attributes. RFC 607 (January 10, 1974) the NIC agrees that NIC maintain a text file of hostnames, addresses, and attributes. (It has also been suggested separately.) The source is maintained in NLS format with multiple attributes. (What is this NLS format?) A program could be written to generate a weekly ASCII file. They will write the program and the generated file will be at OFFICE-1 (IMP #43?) with pathname of <NETINFO>HOSTS.TXT (It's not Unix. It's TENEX I think. The ">" is the directory delimiter, but what is "<"?) I have found a few copies of a hostname table, like https://emaillab.jp/pub/hosts/1974/host_names_1974.pdf and https://www.bortzmeyer.org/files/hosts.txt-1982-1.pdf But these don't appear to be the machine parseable files as defined in the RFC 608 format. These are just printed formats. (I have also found many of the host status reports.) Well I cannot find a copy of the HOSTS.TXT file anywhere. I am not looking for the RFC 810 (1 March 1982) or later format (which is easily found). http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_3_19910112/01/utility/ps-p… may have copies of it (old format is OHOSTS.TXT). But I cannot figure out if or where there are individual file downloads there. Any ideas?) That leads me to my question ... does anyone know where parser code for the HOSTS.TXT file is at? 2) I skimmed through some C code (for Unix) for sendmsg, mmdf, srvrftp, mailer.c, telnet.c that use /dev/net/ followed by up to 14-character hostname. I am trying to find the kernel code or routines that enable device driver named with a hostname. Any ideas? (In particular I'd like to know how those names map to a remote host's address.) I am researching 1970's symbolic name to network address mapping routines, but the only ones I have found are primitive: Purdue's "modest UNIX network" using mx and Berkeley's Berknet (single letter hostnames). But both use simple compiled-in name-to-address tables. (The Purdue implementation looks interesting as it has some design to connect between IMPs too, but I don't see any code for finding IMP numbers via names. By the way, their "csh" tool was their "connected shell" to run a shell on a remote host. The manual had the list of hostnames in it. See the Purdue usenix tape.) Thanks, Jeremy C. Reed echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \ tr '#-~' '\-.-{'

6 years, 2 months

Paper discussing Unix boot process?

by Pat Barron

Long ago, I could swear I'd read a paper (or a TM, or something) that described the process of a Unix system booting. It presented a timeline describing the sequence of how the boot blocks are loaded, the kernel is loaded, MMU turned on, etc. However, other than that, I can't recall a thing about it - can't remember the title, the author, or where I found it. I don't remember if it talked about this process on a Bell Labs Unix system, or a BSD system (though it had to be one of those - either 7th Edition or BSD). The timeframe was probably mid to late 1980's, though I could be wrong about that. Does this ring a bell with anyone? I really wish I could find it again... --Pat.

6 years, 2 months

Talk about some interesting things about Dennis

by Norman Wilson

What is Dennis's character? Is he very humorous? Thank you. He was more humorous when he was still alive, but I think he would have appreciated this joke. Norman Wilson Toronto ON

6 years, 2 months

Talk about some interesting things about Dennis

by Caipenghui

Hello, everyone! Can you share some interesting things around Dennis? What is Dennis's character? Is he very humorous? Thank you. Caipenghui

6 years, 2 months

Re: [TUHS] Paper discussing Unix boot process?

by Paul Ruizendaal

Maybe xv6 has an explanation of the boot process that is of use to the original poster: https://pdos.csail.mit.edu/6.828/2018/xv6.html Paul

6 years, 2 months

Re: [TUHS] Paper discussing Unix boot process?

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > The Multics System Initialization Program Logic Manual. 139 pages of > somewhat detailed information. I was going to mention the Multics init PLM! :-) Needless to say, it's probably not a good candidate for the original goal - a document describing how an OS boots - it's simply too complicated for ordinary mortals! (Reading it makes _my_ head hurt!) There are a couple of reasons it's so complex. Multics is not a monolitic OS, the way most versions of Unix are (although I gather this is no longer quite true of Linux); the OS isn't this large blob of bits you load into memory and start. Its structure makes heavy use of the segmentation model supported by the hardware. Moreover, although the first segments loaded aren't paged, many of the later ones are. (This makes sense in the context of the times; with limited core main memory, you wouldn't want to devote massive chunks of main memory to have the entire OS always resident.) However, this all makes for a more complex booting process; the standard Multics boot tape (a Multics System Tape) contains many modules, which get linked in individually at boot time. (In V6 terms - the version I'm most familiar with - it's as if a Unix boot tape contained 'lib1' and 'lib2', and the bootstrap included a linker to build the OS binary in memory.) And in fact the modules come in in tranches, and some of the earlier one are available for use in loading later tranches (e.g. paging). This does have some advantages, though; e.g. the MST is the same for all Multics machines (including the initial boot of a new machine); the system is customized to the particular configuration during the bootstrap process. This is actually not too crazy, there are reasons this makes sense. For one, the whole 'information utility' concept (where Multics admittedly went down the wrong path, in terms of the future of computers); a single giant machine (multi-processor, multi-memory bank, multi-I/O controller). The thing is that any of these could be switched out if it developed a fault, but then you have to be able to boot that new configuration. (In particular, Multics wasn't a master-slave multi-processor system, they're all the same; but only one CPU runs for most of booting, the others are started and added once the system is running. But the 'bootstrap CPU' might change if the original bootstrap CPU develops a fault...) Noel

6 years, 2 months

Also, VCF SE

by Warren Toomey

And Earl Baugh just let me know: VCF SE at the end of April will have Douglas McIlroy coming to speak. We also will have a number of Unix exhibits as well. Unix is the topic of the front of the show shirt. Earl http://vcfed.org/wp/festivals/otherevents/vintage-computer-festival-southea…

6 years, 2 months

Re: [TUHS] Paper discussing Unix boot process?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> > That's all I knew at the time :-) :-) I used nroff/troff for a bit, but I didn't like it; I don't recall why, but I suspect I wasn't using people's macro packages, which probably made it more difficult to use. My favourite was SCRIBE, but it alas seems to have died. > From: Dan Cross <crossd(a)gmail.com> >> the original Western Electric copies are not troff'ed and run through >> a typesetter ... > Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be, > roughly, a facsimile of line printer output. ... > Interestingly, the title page appears to be approximately original and > is typeset. I finally located my copy of the reprint (I'd been using it to help Fritz Mueller find a problem in his RK11C, and it wasn't in its normal place), and comparing it with my 'samizdat' set (which came from a set owned by Lincoln-Sudbury High School - they actually had an -11 running V6, I helped their computer person, I forget his name now, with it), I can confirm that: - The reprint does mostly reproduce the exact page images from the original (which was indeed, mostly line-printer out), except that the original does not have the typeset chapter/section header pages. It's possible that the pages in the reprint are a new printing, but if so, they have exactly matched not only the layout (not too hard) of the original, but also the font. - In a couple of places (e.g. Contents, pg. 1; Preface, pg. 1; Chapter One, pg. 1) "UNIX" has been replaced by "UNIX*" (different font), and at the bottom of the page has been added "* UNIX is a Trademark of Bell Laboratories", again in a different font. - The typeset 'Source Code' title page is in the original; the copy in the reprint is an exact image, except that the upper-case "This information ... Written permission of Bell Laboratories" section is not in the original, which says instead at that place: "This document may contain information covered by one or more licenses, copyrights and non-disclosure agreements. Circulation of this document is restricted to holders of a license for the UNIX Software System from Western Electric. All other circulation or reproduction is prohibited." - The typeset 'Commentary' title page is different in my samizdat First Edition original; it's a copy of the other title page, except that the second para is replaced by the first sentence of the 'Commentary' title page of the reprint, and of course the title is different from the other volume. Noel

6 years, 2 months

Re: [TUHS] "Fork considered harmful"

by jnc＠mercury.lcs.mit.edu

> From: Richard Salz > Any view on this? > https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ Having read this, and seen the subsequent discussion, I think both sides have good points. What I perceive to be happening is something I've described previously, but never named, which is that as a system scales up, it can be necessary to take one subsystem which did two things, and split it up so there's a custom subsystem for each. I've seen this a lot in networking; I've been trying to remember some of the examples I've seen, and here's the best one I can come up with at the moment: having the routing track 'unique-ID network interface names' (i.e. interface 'addresses') - think 48-bit IEEE interface IDs' - directly. In a small network, this works fine for routing traffic, and as a side-benefit, gives you mobility. Doesn't scale, though - you have to build an 'interface ID to location name mapping system', and use 'location names' (i.e. 'addresses') in the routing. So classic Unix 'fork' does two things: i) creates a new process, and ii) replicates the environment/etc of an existing process. (In early Unix, the latter was pretty simple, but as the paper points out, it has now become a) complex and b) expensive.) I think the answer has to include decomposing the functionality of old fork() into several separate sub-primitives (albeit not all necessarily directly accessible to the user): a new-process primitive, which can be bundled with a number of different alternatives (e.g. i) exec(), ii) environment replication, iii) address-space replication, etc) - perhaps more than one at once. So that shell would want a form of fork() which bundled in i) and ii), but large applications might want something else. And there might be several variants of ii), e.g. one might replicate only environment variables, another might add I/O channels, etc. In a larger system, there's just no 'one size fits all' answer, I think. Noel

6 years, 2 months

"Fork considered harmful"

by Richard Salz

Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

6 years, 2 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