[ih] "network unix"

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > below is what I recently sent to him.  It's all first hand from my
    > personal experience.

A few notes/corrections:

    > The /40 design utilized a single address space for instructions and
    > data, so everything had to fit in 32KB of memory (yes K, not M or G).

Err, that was 32KW, i.e. 64KB. But 8KB was the I/O page (device registers), so
only 56KB of memory - sort of, because V6 Unix used one 8KB page to map in
each process' kernel stack + other swappable per-process data, so really only
48KB for all kernel code, data, disk buffers, etc.

    > MOS, which was SRI's operating system for the LSI-11.

A small real-time memory-only OS; no memory management, or pre-empting of
processes (which were all created when a configuration file was assembled,
prior to linking). It provided inter-process message passing, memory
allocation, asynchronous queued device I/O (using messages for completion
notification), timers and not a whole lot more. It did have character/string
I/O to serial lines.

    > there wasn't enough room in the 32K world for much at all after the
    > basic V6 kernel

We had the same issue at MIT (a couple of years later). We went a very
slightly different direction: we put input packet de-multiplexing in the
kernel, but like yours, everything else (TCP and application) ran in a user
process. The interface between the user and kernel was completely different,
though.

We had several different TCP implementations, semi-tuned to the application:
e.g. the one for FTP had real buffering, for major data flows, but the one for
User Telnet used (effectively) a shift register for buffering transmitted data
(keystrokes).

    > But does the TCP read from the user side, expecting the user to type
    > next?  Or does it read from the network side, expecting the remote
    > program (actually the remote TCP) to send next?  There's no way to tell.

The classic way to handle this problem in 'original' Unix is to have the
process fission, and have one process for each direction; for coordination
between the two, if the two have a pipe between them, they can use signals to
wake each other up and notify the partner that there's data in the pipe to be
read.

Painful, but it does work. I don't recall if our Telnet used this hack; I know
the program we used to talk over serial lines to consoles of the various
LSI-11 routers, etc (which were connected to our time-sharing Unix) used it
(not our group's code, someone else's clever idea).

	Noel