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, 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.