Hi all, I think the current layout of the Unix Archive at
http://www.tuhs.org/Archive/ is starting to show its limitations as we get
more systems and artifacts that are not specifically PDP-11 and Vax.
I'm after some suggestions on how to reorganise the archive. Obviously
there are many ways to do this. Just off the top of my head, top level:
- Applications: things which run at user level
- Systems: things which have a kernel
- Documentation
- Tools: tools which can be used to deal with systems and files
Under Applications, several directories which hold specific things. If
useful, perhaps directories that collect similar things.
Under Systems, a set of directories for specific organisations (e.g. Research,
USL, BSD, Sun, DEC etc.). In each of these, directories for each system.
Under Documentation, several directories which hold specific things. If
useful, perhaps directories that collect similar things.
Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs
for the specific tools.
Does this sound OK? Any refinements or alternate suggestions?
Cheers, Warren
Hi all, to quickly answer one recent question. If you want to upload
something Unix-related for me to archive, you can anonymous ftp upload to
ftp://minnie.tuhs.org/incoming/
Nobody can list the directory contents, so it's good for sensitive files.
If you upload something called xyz, can you also add xyz_Readme which might
describe e.g. what the thing is, where it came from, file format (e.g.
floppy images), how to install it, any other useful information.
If you think it can be added to the public Unix Archive at
http://www.tuhs.org/Archive/, or if the file definitely can't be added
and I should move it to the hidden archive, also say so. Also feel free
not to disclose your identity.
Cheers, Warren
P.S Work has become busy this year. I might call for people to help
out with the curation. Any volunteers? Discretion is a pre-requisite.
> From: Atindra Chaturvedi
> including the Mt. Xinu Mach 386 distro. I still have it and will happily
> send it to the archives
Oh, that's fantastic. It's so important that everyone who has these chunk of
computing history make sure they make it into repositories!
> I have my books and the software for all the cool stuff as it came out
> in those days - some day I will compile it and send it to where it can
> be better used or archived as history.
Please do! And everyone else, please emulate! (I'm already doing my bit! :-)p
Noel
> OK, we're starting to get through all the clearances needed to release
> the non-MIT Unix systems
We have now completed (as best we can) the OK's for the 'BBN TCP/IP V6 Unix',
and I finally bestirred myself to add in the documentation I found for it,
and crank out a tarball, available here:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/bbn.tar
It includes all the documentation files I found for the Rand and BBN code (in
the ./doc directory); included are the original NROFF source to the two Rand
publications about ports, and several BBN reports.
This is an early TCP/IP Unix system written at BBN. It was not the first
TCP/IP Unix; that was one done at BBN in MACRO-11, based on a TCP done in
MACRO-11 by Jim Mathis at SRI for the TIU (Terminal nterface Unit).
This networking code is divided into three main groups. First there is
code for the kernel, which includes IPC enhancements to Unix, including
Rand ports, as well as further extensions to that done at BBN for the
earlier TCP - the capac() and await() calls. It also includes a IMP
interface driver (the code only interfaced to the ARPANET at this point in
time). Next, TCP is implemented as a daemon which ran as a single process
which handled all the connections. Finally, other programs implement
applications; TELNET is the only one provided at this point in time.
The original port code was written by Steven Zucker at Rand; the extensions
done at BBN were by Jack Haverty. The TCP was mostly written by Mike
Wingfield, apparently with some assistance by Jon Dreyer. Dan Franklin
apparently wrote the TELNET.
Next, I'll be working on the MIT-CSR machine. That's going to take quite a
while - it's a whole system, with a lot of applications. It does include FTP,
SMTP, etc, though, so it will be a good system for anyone who wants to run V6
with TCP on a /23. We'll have to write device drivers for whatever networking
cards are out there, though.
Noel
> From: Larry McVoy
> Are you sure? Someone else said moshi was hi and mushi was bug. Does
> mushi have two meanings?
Yes:
http://www.nihongodict.com/?s=mushi
Actually, more than two! Japanese is chock-a-block with homonyms. Any
given Japanese word will probably have more than one meaning.
There's some story I don't quite recall about a recent Prime Minister who
made a mistake of this sort - although now that I think about it, it was
probably the _other_ kind of replication, which is that a given set of kanji
(ideograms) usually has more than one pronunciation. (I won't go into why,
see here:
http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading
for more.) So he was reading a speech, and gave the wrong reading for a word.
There is apparently a book (or more) in Japanese, for the Japanese, that lists
the common ones that cause confusion.
A very complicated language! The written form is equally complicated; there
are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there are
several completely different written forms!
Noel
Follow-up to Larry's "Mushi! Mushi!" story
(http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html)
I showed this to a Japanese acquaintance, who found it hilarious for a
different reason. He told me that a s/w bug is "bagu" -- a
semi-transliteration -- and "mushi" is "I ignore you". So corporate
called, asked for status, and the technical guy said "I am going to
ignore you!" and then hung up.
N.
I have found a video by Sandy Fraser from 1994 which discusses the Spider network (but not the related Unix software). The first 30 min or so are about Spider and the ideas behind it, then it moves on to Datakit and ATM:
https://www.youtube.com/watch?v=ojRtJ1U6Qzw
Although the thinking behind them is very different, the "switch" on the Spider network seems to have been somewhat similar to an Arpanet IMP.
Paul
==
On page 3 of the Research Unix reader (http://www.cs.dartmouth.edu/~doug/reader.pdf)
"Sandy (A. G.) Fraser devised the Spider local-area ring (v6) and the Datakit switch (v7) that have served in the lab for over a decade. Special services on Spider included a central network file store, nfs, and a communication package, ufs."
I do not recall ever seeing any SPIDER related code in the public V6 source tree. Was it ever released outside Bell Labs?
From a bit of Googling I understand that SPIDER was a ATDM ring network with a supervisor allocating virtual circuits. Apparently there was only ever one SPIDER loop with 11 hosts connected, although Fraser reportedly intended to create multiple connected loops as part of his research.
The papers that Fraser wrote are hard to find: lots of citations, but no copies, not even behind pay walls. The base report seems to be:
A. G. FRASER, " SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974.
Is that tech report available online somewhere?
Tanks!
Paul
> From: Random832
> You could return the address of the last character read, and let the
> user code do the math.
Yes, but that's still 'design the system call to work with interrupted and
re-started system calls'.
> If the terminal is in raw/cbreak mode, the user code must handle a
> "partial" read anyway, so returning five bytes is fine.
As in, if a software interrupt happens after 5 characters are read in, just
terminate the read() call and have it return 5? Yeah, I suppose that would
work.
> If it's in canonical mode, the system call does not copy characters into
> the user buffer until they have pressed enter.
I didn't remember that; that TTY code makes my head hurt! I've had to read it
(to add 8-bit input and output), but I can't remember all the complicated
details unless I'm looking at it!
> Maybe there's some other case other than reading from a terminal that it
> makes sense for, but I couldn't think of any while writing this post.
As the Bawden paper points out, probably a better example is _output_ to a
slow device, such as a console. If the thing has already printed 5 characters,
you can't ask for them back! :-)
So one can neither i) roll the system call back to make it look like it hasn't
started yet (as one could do, with input, by stuffing the characters back into
the input buffer with kernel ungetc()), or ii) wait for it to complete (since
that will delay delivery of the software interrupt). One can only interrupt
the call (and show that it didn't complete, i.e. an error), or have
re-startability (i.e. argument modification).
Noel
> From: Paul Ruizendaal
> There's an odd comment in V6, in tty.c, just above ttread():
> ...
> That comment is strange, because it does not describe what the code
> does.
I can't actually find anyplace where the PC is backed up (except on a
segmentation fault, when extending the stack)?
So I suspect that the comment is a tombstone; it refers to what the code did
at one point, but no longer does.
> The comment isn't there in V5 or V7.
Which is consistent with it documenting a temporary state of affairs...
> I wonder if there is a link to the famous Gabriel paper
I suspect so. Perhaps they tried backing up the PC (in the case where a system
call is interrupted by a software interrupt in the user's process), and
decided it was too much work to do it 'right' in all instances, and punted.
The whole question of how to handle software interrupts while a process is
waiting on some event, while in the kernel, is non-trivial, especially in
systems which use the now-universal approach of i) writing in a higher-level
stack oriented language, and ii) 'suspending' with a sub-routine call chain on
the kernel stack.
Unix (at least, in V6 - I'm not familiar with the others) just trashes the
whole call stack (via the qsav thing), and uses the intflg mechanism to notify
the user that a system call was aborted. But on systems with e.g. locks, it
can get pretty complicated (try Googling Multics crawl-out). Many PhD theses
have looked at these issues...
> Actually, research Unix does save the complete state of a process and
> could back up the PC. The reason that it doesn't work is in the syscall
> API design, using registers to pass values etc. If all values were
> passed on the stack it would work.
Sorry, I don't follow this?
The problem with 'backing up the PC' is that you 'sort of' have to restore the
arguments to the state they were in at the time the system call was first
made. This is actually easier if the arguments are in registers.
I said 'sort of' because the hard issue is that there are system calls (like
terminal I/O) where the system call is potentially already partially executed
(e.g. a read asking for 10 characters from the user's console may have
already gotten 5, and stored them in the user's buffer), so you can't just
simply completely 'back out' the call (i.e. restore the arguments to what they
were, and expect the system call to execute 'correctly' if retried - in the
example, those 5 characters would be lost).
Instead, you have to modify the arguments so that the re-tried call takes up
where it left off - in the example above, tries to read 5 characters, starting
5 bytes into the buffer). The hard part is that the return value (of the
number of characters actually read) has to count the 5 already read! Without
the proper design of the system call interface, this can be hard - how does
the system distinguish between the _first_ attempt at a system call (in which
the 'already done' count is 0), and a _later_ attempt? If the user passes in
the 'already done' count, it's pretty straightforward - otherwise, not so
much!
Alan Bawden wrote a good paper about PCLSR'ing which explores some of these
issues.
Noel
