I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Back when it was all UUCP, a friend setup his own system, bang.
He then used his initials as his login, bam.
So when asked for his email address he answered
bang bang bang bam
Bret was a funny guy.
Forwarded with permission.
On Sunday, 18 September 2016 at 9:07:45 -0700, Kirk McKusick wrote:
> On Monday, 12 September 2016 at 11:33:48 +0200, Joerg Schilling wrote:
>> norman(a)oclsc.org (Norman Wilson) wrote:
>>> I don't think the BSD kernel when adopted had much, if any,
>>> of sockets, Berkeley's TCP/IP, McKusick's FFS; if it did,
>>> they were excised. Likewise any remaining trace of V7's
>>> mpx(2) multiplexed-file IPC.
>> From looking at the CSRG sources, it seems that the filesystem
>> project has been founded by Bill Joy and Kirk approached the project
>> a year (or more) later and implemented only the parts that are
>> related to the block allocation.
>> Does someone know more?
> The 4.1a distribution had the initial socket interface with a
> prerelease of the BBN TCP/IP under it. There was wide distribution
> of 4.1a. The 4.1b distribution had the fast filesystem added and
> a more mature socket interface (notably the listen/accept model
> added by Sam Leffler). There was very limited distribution of 4.1b.
> The 4.1c distribution had the finishing touches on the socket
> interface and added the rename system call to the filesystem.
> It also added the reliable signal interface. There was very wide
> distribution of 4.1c as there was a 9-month delay in the distribution
> of 4.2BSD while DARPA, BBN, and Berkeley debated whether the prerelease
> of BBN's TCP/IP should be replaced with BBN's finished version. In
> the end the TCP/IP was not replaced as it had had so much field
> testing and improvement by the folks running the BSD releases that
> it was deemed more performant and reliable. There had been a plan
> to release 4.1d that would have the new virtual memory (mmap)
> interface, but the delay in getting out 4.2BSD caused that addition
> to be delayed for the 4.3BSD release.
> As far as the filesystem is concerned, Bill Joy had done an initial
> design primarily coming up with the idea of cylinder groups as a
> way to distribute the block and inode bitmaps across the disk in
> manageable size pieces. When he handed the project off to me I
> received a single header file that defined his prototype for the
> superblock and the cylinder group structures. I did all of the
> coding from there with Bill doing design review. My feedback from
> the folks at the labs was that they were not interested in incorporating
> the fast filesystem because it tripled the size of the filesystem
> code (from 400 to 1200 lines) and because it needlessly put
> functionality into the kernel that could be done in userland
> (mkdir/rmdir/rename which together were 400 of the 1200 lines of code).
> Kirk McKusick
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
So the "Odd Comments and Strange Doings in Unix" page:
mentions (at the bottom) a "PDP-11/20 with KS-11 add-on". I'm trying
to find info about the KS11, but haven't been able to locate anything.
Does anyone have info on it, or, failing that, is there source for an early
version of Unix that uses it? (I can create something of a User's Manual for
it by reverse engineering from the source.)
I'm looking for old tarballs of mawk. Specifically all versions of
mawk 1.2 and mawk 1.3 prior to 1.3.2. I found a 1.3.2 tarball on the
net (not sure how authentic it is ; if you have a real one, please let
me know) and I have 1.3.3.
> Interesting, but then nobody did run a modern shell on one of these machines or
> everybody did type slowly, so the character lossage problem did not occur.
I'm afraid I don't get the point, apparently something about the
relative performance of stream- and non-stream tty drivers. How
do shells get into the act? And didn't uucp, which was certainly
not a slow typist, appear like any dial-up connection and thus
use /dev/ttyxx? (I cannot recollect, though, when dial-up uucp
"Re-port" may be a bit strong. Internet stuff from Berkeley
was folded into the research code (for a huge increase in
kernel size). But I think it was done by pasting Berkeley
code into local source, rather than the other way around.
Actually it was more nearly:
-- Adopt 4.1c BSD kernel
-- Graft in Research-specific things it was important to
keep: in particular Dennis's stream subsystem, Tom Killian's
original /proc, Peter Weinberger's early network file system
client code (the server was just a user-mode program) and
simple hackery to speed up the file system without great
fuss (make the block size 4KiB and move the free list to
a bitmap; no cylinder groups or other radical changes).
Also device drivers to support Datakit, at the time our
workhorse network. I think a file-system switch went
in early as well, spurred by having both /proc and
pjw's network file system; it wasn't used to support
multiple disk-file-system layouts, though it could have
-- Outside the kernel, keep pretty much the then-current
Research commands, including Blit/5620 support, the
cleaned up and slightly-extended Bourne shell, and whatnot.
I don't think the BSD kernel when adopted had much, if any,
of sockets, Berkeley's TCP/IP, McKusick's FFS; if it did,
they were excised. Likewise any remaining trace of V7's
mpx(2) multiplexed-file IPC.
I'm going by the state the system was in when I arrived
in August 1984, plus a short note written by Weinberger
that I came across later.
TCP/IP support didn't show up until later, I think summer
1985, though it might have been a year later. The first
cut was done by Robert T. Morris (later famous for a buggy
program that broke the Internet), who did several summers
as an intern; he took the code from (I think) 4.2 BSD,
and constructed some shims to fit it into the stream world.
Paul Glick later cleaned it up a lot, removing the need
for most of the shimmery.
Further evolution followed, of course, including a
complete rewrite of the interface between drivers
(device, file system, and stream) and the rest of the
system, which made configuration much more straightforward.
Also a rampage on my part to identify code that was no
longer useful and kick it out; I took special pleasure
in removing ptrace(2) (even though I had to change adb
and sdb first to use /proc).
But that was all later.
Gerard Holzmann took the true and false commands as
the jumping-off point for "Code Inflation", an
installment of his "Reliable Code" blog and column
in IEE Software. An informative, but depressing, read:
The earliest stream-I/O-system-based tty driver I'm aware of was
already in the Research kernel when I interviewed at Bell Labs
in early 1984. I have a vague memory that it was a couple of
years older than that, but I cannot find any citations to
back up either of those memories.
Dennis described streams in the special Unix issue of the
BSTJ, Oct 1984, and noted that "it runs on about 20 machines in
... Research ... Although it is being investigated in other
parts of AT&T Bell Laboratories, it is not generally available."
The manuscript was received October 18, 1983.
Because of the design bug I mentioned, I searched for UNIX sources from AT&T
that include streams support, but could never find any.
None of the Research systems after 32/V was ever distributed except
to a handful of sites under site-specific letter agreements that
This is a bug, not a feature, but there it is. It was easy to get
approval to write a paper, much harder to get permission to distribute
code, especially when the code in some way overlapped the Official
Warren and I (and Dennis, when he was still alive) hoped to do
something about some years back, but it's a lot harder than it used
to be because it is harder to find a corporate entity that is
confident enough to give permission, even for stuff that is so old
that it is unlikely to have a trumppenceworth of commercial value.
Then IBM vs SCO intervened, and now things are even more fragmented.
There may be other efforts under way now and then to negotiate the
legal minefield. I wish them all well, and will help them where I