[TUHS] V8, V9 and V10 now in the "Unix Tree"

[Paul Ruizendaal <pnr@planet.nl>]

Many thanks for the below notes!

Some comments in line below:

> The initial user-mode environment was a mix of 32V,
> subsequent work within 1127, and imports from 4.1BSD.
> I don't know the exact heritage: whether it was 1127's
> work with 4.1BSD stuff added or vice-versa.

Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later.

> The kernel was a clean break, however: 4.1xBSD for some
> value of x (probably 4.1a but I don't remember which)
> with Research changes.

I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort.

As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/*	vmmem.c	4.7	81/07/09	*/“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?)

For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition.

As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet).

> -- Berkeley FFS replaced by Weinberger's bitmapped
> file system: essentially the V7 file system except
> the free list was a bitmap and the blocksize was 4KiB.

Thank you for pointing this out. With my focus on networking I had completely missed that.

> Hacky implementation, depending on a flag bit in the
> minor device number; didn't use the file system switch.
> Old 512-byte-block file systems had to be supported
> partly to ease the changeover, partly because the first
> version had a limited bitmap size so file systems larger
> than about 120MiB wouldn't work.

For those interested, some of the relevant files are:
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’)

And indeed the bitmap was fitted inside the 4KB superblock, 
> This limit was removed
> later.  (In retrospect I'm surprised I didn't then insist
> on converting any remaining old-format file systems in
> our domain and then removing the old-format code from
> the kernel, since user-mode tools--including a user-mode
> file server!--could be used to access any old disks
> discovered later.)
> 
> For the purposes of Paul's note it probably suffices
> just to say that there was a restart with a 4.1-series
> kernel with changes as he describes, except also the
> new file system format.