12 Apr
2020
12 Apr
'20
11:30 a.m.
Oops - pressed send too soon - apologies
—
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, 961 longs.
961 x 32 bits x 4KB = 120MB
I’m not sure I understand the link between cluster and page size that is mentioned in
param.h
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.)