[TUHS] PDP-7 UNIX filesystem

[Abhinav Rajagopalan]

Thanks, mkdir actually seems to go back to V4.

Also, V4 was the first to have the kernel in a 'high level language' C,
from the V4 tree,

The files in nsys/ come from nsys.tar.gz
> <http://minnie.tuhs.org/Archive/Distributions/Research/Dennis_v3/nsys.tar.gz>,
> which was donated by Dennis Ritchie. This is a version of the kernel quite
> close to that released in Fourth Edition, but *without pipes*. Dennis
> Ritchie writes:



> This is a tar archive derived from a DECtape labelled "nsys". What is
> contains is just the kernel source, written in the pre-K&R dialect of C. It
> is intended only for PDP-11/45, and has setup and memory-handling code that
> will not work on other models (it's missing things special to the later,
> smaller models, and the larger physical address space of the still later
> 11/70.) It appears that it is intended to be loaded into memory at physical
> address 0, and transferred to at location 0.


The efforts behind the PDP-7 file system were quite tedious and was a
general directed graph, only word addressable which meant lack of path
names as it ignored null chars, the link call being used to link
directories together which is where dd arises as the precursor to .. today.
The required files for the user was just linked in together in their dirs.

Quoting from DMR's Evolution of the Unix Time-sharing system,

So that every user did not need to maintain a link to all directories of
> interest, there existed a directory called *dd* that contained entries
> for the directory of each user. Thus, to make a link to file *x* in
> directory *ken*, I might do

ln dd ken ken
> ln ken x x
> rm ken
>
This scheme rendered subdirectories sufficiently hard to use as to make
> them unused in practice. Another important barrier was that there was no
> way to create a directory while the system was running; all were made
> during recreation of the file system from paper tape, so that directories
> were in effect a nonrenewable resource.


No mkdir/mknode while the system was running, the whole file system had to
be recreated from the paper tape each time! Thank DEC for the PDP-11. And
of course, no pipes until '72. Earlier parent had pondered on the write
permissions required to execute programs, this below explanation from the
paper might help.

Another mismatch between the system as it had been and the new process
> control scheme took longer to become evident. Originally, the read/write
> pointer associated with each open file was stored within the process that
> opened the file. (This pointer indicates where in the file the next read or
> write will take place.) The problem with this organization became evident
> only when we tried to use command files. Suppose a simple command file
> contains

ls
> who

and it is executed as follows:

sh comfile >output

The sequence of events was

1) The main shell creates a new process, which opens *outfile* to receive
> the standard output and executes the shell recursively.

2) The new shell creates another process to execute *ls*, which correctly
> writes on file *output* and then terminates.

3) Another process is created to execute the next command. However, the IO
> pointer for the output is copied from that of the shell, and it is still 0,
> because the shell has never written on its output, and IO pointers are
> associated with processes. The effect is that the output of *who*
> overwrites and destroys the output of the preceding *ls* command.

Solution of this problem required creation of a new system table to contain
> the IO pointers of open files independently of the process in which they
> were opened.


Source: https://www.bell-labs.com/usr/dmr/www/hist.html



On Mon, Oct 21, 2019 at 5:28 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Abhinav Rajagopalan
>
>     > I only now realized that only mknod existed, up until a long time,
> only
>     > later on with the GNU coreutils did mkdir as a command come into
>     > existence.
>
> Huh? See:
>
>     https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/man/man1/mkdir.1
>
> (And probably before that, that was the quickest one to find?)
>
> Maybe that was a typo for 'mkdir as a system call'? (I recall having to do
> a
> fork() to execute 'mkdir', back when.) But 4.2 had mkdir().
>
>        Noel
>
>

-- 

Abhinav Rajagopalan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20191021/1ac61853/attachment.html>