Matt,

This is wonderful work.  Thank you.

Clem

On Mon, May 15, 2023 at 12:28 AM segaloco via TUHS <tuhs@tuhs.org> wrote:

> I've just completed the Fourth Edition pass of commits in my manual
> history repository here: https://gitlab.com/segaloco/mandiff
>
> Something I've kept a particular eye on is what the landscape looked like
> on the filesystems over the early years of development.  Here are some of
> those observations with a few areas perhaps requiring further illumination:
>
> In the first two editions, there was a file, /etc/uids, which mapped
> simply a username to a uid.  The reason was presumably due to the plaintext
> passwords in /etc/passwd at the time.  The arrival of crypt(III) and
> related functionality rendered this moot by the time of V3.  Additional
> GECOS information is first spotted in /etc/ident in V2 but by V3 has also
> found home in /etc/passwd in the GECOS field today used often for a user's
> full name.  The s1-bits source codes refer to /etc/passwd where
> disassembled s2-bits binaries refer to /etc/uids still, dating both sets of
> code.
>
> References to /etc/motd first appear in the V2 manual from what I could
> find, so that may not have been around in V1.  Additionally, after V1 many
> files are moved from /etc to locations under /usr such as ascii and kbd
> moving to /usr/pub and roff's suftab moving to /usr/lib.  It seems in the
> First Edition, manual section VII mapped to /etc itself it seems, with etc
> and misc in the manual being synonymous.
>
> So all in all it seems, in terms of support files anyhow, /etc wound up
> smaller by the advent of the C system, at which point init beings using
> /etc/rc and the directory begins to expand again.
>
> Another directory of interest is /sys for a few reasons.  First, this
> directory serves different purposes depending on your kernel these days,
> with BSD systems storing system source code here whereas Linux provides a
> kernel interface filesystem.  I'm not sure what other contemporary systems
> may use this for, but from V3 and back, this was another RK disk mounted in
> addition to /usr.  This /sys directory appeared to contain the manuals,
> source code to system components including the commands, kernel,
> bootloader, and languages, and a copy of the kernel image referenced down
> in the source tree.
>
> In total I've identified the following directories: c, fort, lang, man,
> mdec, source, sys.  Most names should be obvious from later releases, with
> lang being a parent directory that contained bdir and mdir B and m6
> languages respectively.  My guess is that when RP support was made workable
> in V4, there was no longer a need to segregate data amongst RKs like this
> so /sys was merged into /usr, leading to the later structure we see in
> V4-V6.  Of note, this structure is implied in CB-UNIX still in the path
> names of the source code available on the archive.  The kernel is found at
> /tsys/sys/ much like the kernel in V1-V3 living at /sys/sys.
>
> One thing I haven't been able to glean in the process is precisely how the
> command and library source code was stored in these very early versions.
> The kernel in T.R. Bashkow's analysis is implied to be stored in files
> u[0-9x].s, and command source files at least exist somewhere as the command
> followed by .s.  As of V5, the command, syscall wrapper, and library source
> codes are split up amongst a number of directories with names such as s1,
> s2, s3, etc. under source.  By V7, this has taken on the cmd/lib/sys
> structure of later releases.
>
> Finally, just a general curiosity the version study involved has raised.
> Given the movement of UNIX to the 11/45 and then to C, does the Third
> Edition represent a version of UNIX for the 11/45 with protection but
> written in assembly, not C?  I've seen one handwritten document that makes
> mention of some of this, but is there any other information such as
> documents, code, etc. concerning the 11/45 assembly version?  Was work
> completed on the 11/45 kernel changes in the context of this version and
> then simply "ported" to the C version or were there concepts that were
> cropping up in one or the other and varying amounts of transportation back
> and forth as 11/45 and C aspects were implemented?
>
> As always, thanks for keeping up, hopefully I can get this repository up
> to V6 soon, then the real branching fun begins.  The V3 to V4 changes are
> hopefully the last time the commit diffs have major noise, what with the
> conversion from roff to nroff.  I suspect transitions to macro packages
> later won't be as bad.
>
> - Matt G.
>
-- 
Sent from a handheld expect more typos than usual