21 Oct
2019
21 Oct
'19
11:58 a.m.
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
21 Oct
21 Oct
3:44 p.m.
New subject: PDP-7 UNIX filesystem
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
--
Abhinav Rajagopalan
<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(a)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
22 Oct
22 Oct
2:09 a.m.
New subject: PDP-7 UNIX filesystem
On Oct 21, 2019, at 19:58, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
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().
I believe, it was 4.2 (or 4.1c) according to David Tilbrook's paper on rename. The
site qef.com <http://qef.com/> seems to have disappeard, but the wayback machine has
copies[1]
jaap
[1] as example,
https://web.archive.org/web/20070228190911/http://www.qef.com/html/docs/ren…
<https://web.archive.org/web/20070228190911/http://www.qef.com/html/docs/rename.ps>
23 Oct
23 Oct
2 a.m.
New subject: PDP-7 UNIX filesystem
On Mon, Oct 21, 2019, 10:16 PM Jaap Akkerhuis <jaapna(a)xs4all.nl> wrote:
On Oct 21, 2019, at 19:58, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
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().
I believe, it was 4.2 (or 4.1c) according to David Tilbrook's paper on
rename. The site qef.com seems to have disappeard, but the wayback
machine has copies[1]
Timing being everything, I happily have a copy of it all, as I used wget to
pull it into a git repo.
It's doubtless not in "native" form as he used one of his little languages
(that were part of qef) to generate it. But HTML isn't too bad for this.
1653
days inactive
1655
days old
3 comments
4 participants
participants (4)
-
Abhinav Rajagopalan -
Christopher Browne -
Jaap Akkerhuis -
jnc＠mercury.lcs.mit.edu