From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id cc68e966 for ; Mon, 21 Oct 2019 15:45:38 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9B0399B936; Tue, 22 Oct 2019 01:45:37 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CBA3893D91; Tue, 22 Oct 2019 01:45:02 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="pSEHN4/8"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A773B93D91; Tue, 22 Oct 2019 01:44:59 +1000 (AEST) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by minnie.tuhs.org (Postfix) with ESMTPS id B425F93D8C for ; Tue, 22 Oct 2019 01:44:58 +1000 (AEST) Received: by mail-ed1-f48.google.com with SMTP id v8so10397126eds.2 for ; Mon, 21 Oct 2019 08:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fO0LY1NFAYWaML3pStYTWzAhW1koO+n0hWMI7uKbhps=; b=pSEHN4/8fdap/JhUcmN/qvxQt3HpECX9CHXWlS9lE26tSZlOw+vYKJ1zaausgLoCE6 dyF2MBzU/68A8ROo6EA88zP7ZNJ/WHkboel5U2WtKjzZAouU3BYzgvmcLzgR4XApBD/m be16QJqp8pcrbAH4tzPKehERk6EIDZb8uczVVDDCvp1esEaJEYZw0LkWICbOr61vg5Az M1lv0O4kvvFUq/tAxfU5YpUDjwRDAh0+aWLyqVl1qx8BFA4cHuiIuo55UOrY0JiVOcpd tl2VRumMVX+K56LY9FRuhE6cX8ep4DwGtUzybT5qb7x6wFn+IoFdaamE10we8TOwB+4Q HEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fO0LY1NFAYWaML3pStYTWzAhW1koO+n0hWMI7uKbhps=; b=gb9h6KfzCtUjuP5dEe76FyD27RtCsWLZh3t82SDlxNv1wHDj6BFmoqyCBQcRu/57ye Zjd7hlTEKq6koM3kBPIdTA6kzD6Aol7FV6v1uCo8NIcnm6S3fQsELoWsBWfWBAhDHs/u enF9TEG//rX+YyQ1R2nJAj/meltFe5QODz2Rp2fhwEE13HPXOr7kC5F7Uj/MelDoO6ml /nP47hD1IxMgUAPBn6PGsAaks6BXEv0dIICdUlnHWg6578jLd3TEpK8t7HbbzMVjs/6W PKdETSF7oTqJ/O39JMEvA6mrerXKU2eclJrJ7u+RZkoLMLw3CP3YVbEKDHGojLKd1j0U DU9g== X-Gm-Message-State: APjAAAVzEYdpeTzo5yTgYfRojenV1FkeI5wf7YAmEHDxS1fYui6cXiHL XRGLsiEYhugeJm8IdB6pyoBV9RgoOp3jHQzycyYhi65pR/NWyA== X-Google-Smtp-Source: APXvYqxMNCkw+iThsrKiGK9A/4Fary37RPFbTw3Y1wfFCBiIzH9cfW4gbTFjfV/N+AqLMk5KdIokLjEkVMSoHzb9Mus= X-Received: by 2002:a17:906:b318:: with SMTP id n24mr22272659ejz.248.1571672697193; Mon, 21 Oct 2019 08:44:57 -0700 (PDT) MIME-Version: 1.0 References: <20191021115829.C05FB18C09F@mercury.lcs.mit.edu> In-Reply-To: <20191021115829.C05FB18C09F@mercury.lcs.mit.edu> From: Abhinav Rajagopalan Date: Mon, 21 Oct 2019 21:14:20 +0530 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="000000000000d1ca7e05956d908a" Subject: Re: [TUHS] PDP-7 UNIX filesystem X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000d1ca7e05956d908a Content-Type: text/plain; charset="UTF-8" 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. Source: https://www.bell-labs.com/usr/dmr/www/hist.html On Mon, Oct 21, 2019 at 5:28 PM Noel Chiappa 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 --000000000000d1ca7e05956d908a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, mkdir actually seems to go back t= o 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=20 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:
=C2=A0
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 wa= s 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 directorie= s together which is where dd arises as the precursor to .. today. The requi= red files for the user was just linked in together in their dirs.=C2=A0

Quoting from DMR's Evolution of the Unix Time-sha= ring 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 m= kdir/mknode while the system was running, the whole file system had to be r= ecreated from the paper tape each time! Thank DEC for the PDP-11. And of co= urse, no pipes until '72. Earlier parent had pondered on the write perm= issions 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

<= tt>
ls
who
and it is executed as follows:
sh comfile >output
The sequence of event= s 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.=C2=A0
=C2=A0
Source: <= a href=3D"https://www.bell-labs.com/usr/dmr/www/hist.html">https://www.bell= -labs.com/usr/dmr/www/hist.html=C2=A0

<= u>

On Mon, Oct 21, 2019 at 5:28 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrot= e:
=C2=A0 =C2=A0 > From: Abhinav Rajagopalan
=C2=A0 =C2=A0 > I only now realized that only mknod existed, up until a = long time, only
=C2=A0 =C2=A0 > later on with the GNU coreutils did mkdir as a command c= ome into
=C2=A0 =C2=A0 > existence.

Huh? See:

=C2=A0 =C2=A0 https://minnie= .tuhs.org//cgi-bin/utree.pl?file=3DV6/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 havin= g to do a
fork() to execute 'mkdir', back when.) But 4.2 had mkdir().

=C2=A0 =C2=A0 =C2=A0 =C2=A0Noel



--

Abhinav Rajagopalan

=

--000000000000d1ca7e05956d908a--