Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix
Subject: Re:  UNIX History
Message-ID: <1551@rlgvax.UUCP>
Date: Sun, 15-Jan-84 13:57:00 EST
Article-I.D.: rlgvax.1551
Posted: Sun Jan 15 13:57:00 1984
Date-Received: Mon, 16-Jan-84 01:35:03 EST
References: <15460@sri-arpa.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 76


	The UNIX System V IPC was already present in USG UNIX 4.1.
	(Not related to 4.1BSD.)

For you real UNIX trivia freaks, the USG 4.0 IPC was different
from the USG 4.1 IPC.  The original message send/receive system calls sent
to a process ID; they were changed to send to message queues, which had a
32-bit unique ID, instead (which makes more sense, as it permits you to
transparently replace servers).  (It might be interesting to see how many
changes to the Berkeley IPC mechanism would be needed to provide yet another
domain which provides compatibility with the S5 IPC mechanism; obviously,
the socket addresses would be the unique IDs.  The trick is that the S5
messages have a "long" which is a "message type", and the S5 "msgrcv"
call can ask to be delivered only messages of a certain type, or messages with
a certain type number or lower number.  Also, message queues (and other
"IPC objects") have an owner UID, owner GID, and permission bit set
associated with them.)  The semaphore code was also very different (it may
have been descended from semaphore code done for the pre-UNIX/TS USG systems),
and the shared memory code was the MAUS code which used a dedicated part
of physical memory for the shared space.  The history of Bell UNIX IPC
mechanisms looks rather multi-branched; anybody out there with the full
story?

It's also interesting to see mention of various such branches in the BSTJ
issue on UNIX (the July-August 1978 issue, Vol. 57, No. 6, Part 2).  They
make casual reference to "the UNIX interprocess message facility", "the
semaphore capability of the UNIX system", and to "run levels" in "the standard
UNIX 'init' program" in the article on the Network Operations Control System,
and also describe the MAUS shared-memory facility which was originally done
for that system.  (Another aside: the MAUS was credited to Dale DeJager
and R. J. Perdue; I remember seeing some code from Gould which was part of
their driver and support code for their 5000 series electrostatic printer-
plotter for DEC systems which was also credited to R. J. Perdue - was this
the same guy?)  A lot of those features probably came out of Columbus but
never made it into the UNIXes released to the outside world until System III
(the 'init') or System V (the messages and semaphores).  Andy Tannenbaum sent
me a "man" page for an "init" from a pre-UNIX/TS USG system which also had
the run levels, and Hal Pierson (ex-Labs, now working here) mentioned that
they had done both a semaphore system and the run-level based 'init' for a
system they did which collected output from the console terminal ports of
Electronic Switching Systems processors and allowed "craftsmen" (which I
think is AT&Tese for "field engineer") to peruse that output for maintenance
purposes.  They also realized that these craftsmen wouldn't know an inode if
it came up and bit them in the *ss, so they had to replace "icheck" and "dcheck"
with a new program which would do most of the dirty work of file system repair
for them - Hal wrote one called "fcheck", which cleaned V6 file systems, and
which appeared in source-code form on the PWB/UNIX 1.0 distribution tape.
Unfortunately, PWB/UNIX 1.0 modified the V6 file system so that it didn't
support "huge" files, and the eighth indirect pointer pointed directly to
a block as the other seven did, so the "fcheck" there wouldn't fix a vanilla
PWB/UNIX file system, but it worked just fine on a vanilla V6 FS.  When I
discovered it, quite by accident, I looked at it and it sure looked like
a super-duper file system fixer; once we got it up, we never went back to
"icheck" and "dcheck" again.  Later on, of course, Ted Kowalski rewrote it
to work on a V7 filesystem, added some extra checks, gave it the ability
to reconnect files with no directory entries, put comments into the
code (something Hal still has trouble doing :-)), cleaned it up some, and
renamed it "fsck".

	It appears to me that these features must have been in UNIX/RT.

MERT had its own set of new features, including yet *another* message facility
which didn't look like any of the "Ken&Dennis-derived" UNIX systems'
facilities, but I don't know what they did in UNIX/RT.

A lot of source material is in the BSTJ UNIX article, and may appear in some
issues of Bell Labs' "UNIX Systems Newsletter" which was distributed to
UNIX sites within AT&T & operating companies.

Anybody for a "net.unix.history" newsgroup - at the end of the year, maybe
we gather up all the articles, give them to some editor (maybe Dennis, who
certainly doesn't have anything more important to do :-)) who can cull out
the chaff, and publish it somewhere?

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy