Below what I've been able to find about alarm():
[1] Oldest alarm() code I can find is in PWB1, dated July 1977:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.chttp://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/clock.c
Either alarm existed in V5 and V6, and was removed from distributions
(which seems unlikely to me), or is was added after V6 was released,
perhaps soon after. In the latter case the 'nfs' code that we have must
be later than 1974 (even though the man page is dated that way).
It could be from the 2nd half of 1975.
[2] Interestingly, the idea to implement sleep() in terms of alarm()
seems to originate in UoI network unix:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c -- sslep()
This occurs in Oct 1977. In V7 this idea is taken to user space and
sleep() is no longer a system call.
[3] The UoI code has an instance of alarm() being used to break out of
a potentially stalled network call, so that usage seems to have
established itself early on.
Progressed a little further:
[1] The 'ufs' command was a variation on the 'nfs' command. The man page
that Noel provided for nfs includes the paragraph:
"There is a command /usr/usg/tom/ufs which transfers files to
the USG Unix systems. The option letter 7 for the 11/70 or
4 for the 11/45 should be used. Otherwise 'ufs' is similar to
'nfs'."
This means there must have been a Unix based File Store (server).
Does anybody have a suggestion who 'tom' at USG might have been?
[2] The V5 man pages in the archive have a man page for 'npr',
in section VI. It says:
NAME
npr - print file on Spider line-printer
SYNOPSIS
npr file …
DESCRIPTION
Npr prints files on the line, printer in the Spider room,
sending them over the Spider loop. If there are no arguments,
the standard input is read and submitted. Thus npr may be used
as a filter.
FILES
/dev/tiu/d2 tiu to loop
It suggests that the printer was hooked up to the Spider switch and that
channel 2 was hardcoded to it.
[3] Upon closer inspection, the tiu.c driver is a character mode device,
the use of disk buffers and a strategy() routine had me confused.
It is just a reflection of the fact that it uses DMA hardware.
The code for tiu.c in NSYS/V4 is rather different from the code in
the SRI-NOSC tree: thinking on how to select channels seems to have
changed in between these two versions.
[4] Also I found the below post that mentions the snstat() call:
http://minnie.tuhs.org/pipermail/tuhs/2015-December/006286.html
The object code for snstat() is in libc.a in the dmr's V5 image.
Reconstructed, the source code is here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/a93175746bd9f94f
In short, snstat() is a modified stty call, an evolution in the direction of
the later ioctl() system call.
No progress as yet on the early history of 'alarm()'.
Paul
>> It is a paper copy, but I can make a scan for you.
>
> That makes it sounds like it might not be possible to put it online?
> What's the exact title, so I can look and see if it's already online?
> I'm pretty sure I've got a hardcopy of some Spider thing, but it would
> probably take me a while to find it... ;-)
The report I have is:
"SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974.
I did not find it online, but it may be out there somewhere.
I think it can be public now, but doing some checks.
> OK, the only one I have is 'nfs'. Here's the source, and man page:
>
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6
Many thanks! There is some puzzling stuff in there that I'd like to
figure out, but that is easier to discuss once the report is online.
Also, it turns out that the TIU driver was in Warren's repo all along:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.chttp://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man4/tiu.4
It's fun to read that the V4 man page says "The precise nature of the
UNIX interface has not been defined yet." and Noel's version says:
"The precise nature of the UNIX interface is defined elsewhere." (yet
the dates are the same!).
Some things are surprising (to me, at least):
First of all, opening a connection to the File Store is a single open on
data channel 1:
http://chiselapp.com/user/pnr/repository/Spider/artifact/854a591c0e7a3a54?l…
I would expected the code to first have sent a connection request to the
switch on control channel 1. Perhaps the File Store was an integral part
of the switch/router (a Tempo minicomputer
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/tempoComputers/TEMPO-1_ad_Nov69.pdf)
with channel 1 functionality hardwired.
Next, the code has a hackish form of non-blocking I/O:
http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l…
I'm puzzled about the alarm() sys call. That did not exist in 1973 -- or did it
only exist in Bell Labs private builds?
The code calls snstat(), for instance here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l…
That seems to be a sys call to here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/2c7d65073a7cb0a5?l…
Could that be the tiu sys call (#45) in the sysent.c table for V4-V6?
Ok, I just did an experiment with the rm command and the results surprised me.
On Unix v5 logged in as root I created a small test file then did
chmod 444 on it. Unfortunately it appears that mere users can still rm
the file and also directories are not safe from the rmdir command
(even directories set to mode 444).
This seems to be the case for v6 and v7 as well.
To be fair rm will prompt the user with: test1: 0100444 mode
but the user only has to type y and hit enter and the file is toast.
Is there no way to completely protect files from being deleted?
Mark
> From: Paul Ruizendaal
>>> the 1974 report on Spider
>> Is that online? If not, any chances you can make it so?
> It is a paper copy, but I can make a scan for you.
That makes it sounds like it might not be possible to put it online?
What's the exact title, so I can look and see if it's already online?
I'm pretty sure I've got a hardcopy of some Spider thing, but it would
probably take me a while to find it... ;-)
> I think that in the lifespan of Spider (1972-1978) there were 3 main
> network programs (basing myself on McIlroy's Unix Reader):
> - 'nfs' an FTP-like program ...
> - 'ufs' not sure what it was, but I think a telnet-like facility
> - 'npr' a network printing program
OK, the only one I have is 'nfs'. Here's the source, and man page:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.ahttp://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6
Noel
>
>> I'm looking into the history of Spider and early Datakit. Sandy Fraser
>> was kind enough to send me the 1974 report on Spider
>
> Is that online? If not, any chances you can make it so?
It is a paper copy, but I can make a scan for you.
> which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
> are part of it?
I think tiu.c might be all. The TIU ("terminal access unit") was the network card,
so to speak (actually some 5 boards in a rack) and did a lot of the heavy lifting.
From the tiu.c file I understand that a DR11-B parallel I/O card was used on
the PDP side to connect to the TIU, and that access was structured as a block
device driver.
> I'm not at all clear how this stuff got there - someone at Bell must have just
> dumped the contents of the 'dmr' directory, and sent it all off?
Looks like it.
> The PWB1-based MIT systems also have a lot of the Spider software (although it
> was never used). It's a slightly different version than the one above: 'diff'
> shows that 'tiu.c' is almost identical, but mpx.c has more significant
> differences.
>
> It also contains man pages, and sources for some (?) user programs; I have the
> source and manpage for 'nfs'. What other names should I be looking for? (The
> man page for 'nfs' doesn't list any other commands.) I'll put them up
> momentarily.
I think that in the lifespan of Spider (1972-1978) there were 3 main network
programs (basing myself on McIlroy's Unix Reader):
- 'nfs' an FTP-like program to copy files to/from a central File Store.
I'm not sure whether the File Store was a Unix machine or something else.
- 'ufs' not sure what it was, but I think a telnet-like facility
- 'npr' a network printing program
A little surprising, but no reference to a Spider mail program in that document.
> In the meantime, I'll append the 'tiu' man page.
Thanks! It is from October 1973, which sounds right for Spider. I guess this
code is the first networking on Unix, predating the UoI work by about 18 months.
> From: Paul Ruizendaal
> I'm looking into the history of Spider and early Datakit. Sandy Fraser
> was kind enough to send me the 1974 report on Spider
Is that online? If not, any chances you can make it so?
> Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g.
> the 'tiu' device driver, the 'nfs' file transfer package, etc.)?
You're in luck.
To start with, check out:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/oldstuff
which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
are part of it?
I'm not at all clear how this stuff got there - someone at Bell must have just
dumped the contents of the 'dmr' directory, and sent it all off?
The PWB1-based MIT systems also have a lot of the Spider software (although it
was never used). It's a slightly different version than the one above: 'diff'
shows that 'tiu.c' is almost identical, but mpx.c has more significant
differences.
It also contains man pages, and sources for some (?) user programs; I have the
source and manpage for 'nfs'. What other names should I be looking for? (The
man page for 'nfs' doesn't list any other commands.) I'll put them up
momentarily.
In the meantime, I'll append the 'tiu' man page. There isn't one for mpx,
alas.
Noel
--------
.th TIU IV 10/28/73
.sh NAME
tiu \*- Spider interface
.sh DESCRIPTION
Spider
is a fast digital switching network.
.it Tiu
is a directory which contains
files each referring to a Spider control
or data channel.
The file /dev/tiu/d\fIn\fR refers to data channel \fIn;\fR
likewise /dev/tiu/c\fIn\fR refers to control channel \fIn\fR.
.s3
The precise nature of the UNIX interface
is specified elsewhere.
.sh FILES
/dev/tiu/d?, /dev/tiu/c?
.sh BUGS
>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> ...
>> DCEC's adaptation of the Wingfield TCP/IP library, designed to work
>> with V6. It is mostly a user space daemon, but requires some kernel
>> enhancements.
>
> I wonder what the performance would be like, since the TCP is in a user
> process (a different one from the application), i.e. there's a process switch
> every time the application goes to send or receive data. This wouldn't have
> been such an issue when the code was written, since ARPANet-type networks
> were not very fast, but with a better network, it would have been limiting.
IEN98 (http://www.rfc-editor.org/rfc/ien/ien98.txt, page 2) has the answer: about 10kb/s.
The DCEC version used shared memory instead of rand ports and was claimed to be
a bit more performant, but I have no number. I'd be surprised if it was twice as fast,
so perhaps 15kb/s.
Paul
> From: Clem Cole
> So some other mechanism (also discussed here) needed to be created to
> avoid blocking in the application.
> ...
> Rand, UNET & Chaos had something else that gave the save async function,
> who's name I've forgotten at the moment
I don't think the RAND code had the non-blocking stuff; AFAICR, all it had was
named pipes (effectively). Jack Haverty at BBN defined and implemented two new
calls (IIRC, 'capac()' and 'await()') to do non-blocking I/O. The
documentation for that is in the 'BBN' branch at TUHS:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/awaithttp://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ipc
My memory might be incorrect, but I don't think it was asynchronous (i.e. a
process issued a read() or write(), and that returned right away, before the
I/O was actually done, and the system notified the process later when the I/O
actually completed).
I actually did implement asyn I/O for an early LAN device driver - and just to
make it fun, the device was a DMA device, and we didn't want the overhead of a
copy, so the DMA was direct to buffers in the process - i.e. 'raw' I/O. So
that required some major system tweaks, to keep the process from being swapped
out - or moved around - while the I/O was pending.
> I believe Noel posted the code for same in the last year from one of the
> MIT kernels
I found it on the dump of an MIT machine, but it was never run on any machine
at MIT - we just had the source in case we had any use fot it.
Noel
> From: Paul Ruizendaal
> There are two other routes to TCP/IP on a PDP11 without split I/D:
> ...
> DCEC's adaptation of the Wingfield TCP/IP library, designed to work
> with V6. It is mostly a user space daemon, but requires some kernel
> enhancements.
I wonder what the performance would be like, since the TCP is in a user
process (a different one from the application), i.e. there's a process switch
every time the application goes to send or receive data. This wouldn't have
been such an issue when the code was written, since ARPANet-type networks
were not very fast, but with a better network, it would have been limiting.
> From: Steve Simon
> do you have pointers to any documentation on the rand/MIT network API?
There was no 'MIT' network API. He was talking about the CHAOSNet API. The
TCP/IP done in the CSR group at MIT used a totally different API.
The various Unix systems at MIT were pretty well out of touch with each other,
and did not exchange code. The only exceptions were the DSSR (later RTS) and
CSR groups in Tech Sq, who used pretty much the same system.
Noel
