Intruiging bits in the nsys kernel

[norman at nose.cita.utoronto.ca]

Some answers to Warren's queries:

mknod(II) first shows up in the Fourth Edition; the manual entry is dated
8/5/73.  (That having been typed in the US, presumably it means 5 Aug 1973.)
getgid(II) shows in the same manual, but with an older date: 3/15/72.
This is also the edition in which the documentation for stat(II) first
admits a group ID as well as a user ID.

Both my hazy memory (made worse by lack of sleep right now) and the clues
in the manual suggest that 3e/4e was the period when the system was rewritten
in C; e.g. 4e is the first to show C interfaces in section II, complete with
structs as well as pure byte-offset descriptions for objects like that filled
in by stat, though the structs are nameless, presumably because there were no
standard header files yet.  Evidently the file system upheaval occurred in
the same period.

Reading the description of the 3e file system, I see it has been too long since
I've read it.  A summary:
	Blocks 0 and 1 are the super-block, consisting of
		size of free-storage bitmap
		the map itself
		size of free-i-node map
		the map itself
	Block 2 begins the i-list; data blocks follow.
	I-nodes 1-40 are reserved for special (device) files,
	and don't appear in the map.  I-node 41 is the root.
	I-nodes have flags, a link count, a userid, a 16-bit
	size, creation and modification times, and eight block
	pointers.  Flag bits inclode `allocated', `large file'
	(the pointers are to indirect blocks), read and write
	permissions for user and other, set-userid, a single
	`executable' flag, a `directory' flag (if clear, regular
	file).

	BUGS
	Two blocks are not enough to handle the i- and free-
	storage maps for an RP02 disk pack, which contains
	around 10 million words.

The 4e file system is more or less that in the more-familiar V6 system:
	Block 0 reserved for boot block
	Block 1 is the super-block: file-system and i-list sizes,
	caches of free block and i-node numbers.  The free-block
	list is now the familiar chain of blocks list free block
	numbers; the free-inode list is abolished because the
	i-nodes all have `allocated' flags anyway.
	Block 2 begins the i-list.  I-node 1 is the root.
	I-nodes differ from 3e in having a group ID,a 24-bit
	size, access time instead of creation time; the `directory'
	flag becomes a two-bit `file type' flag; group permissions
	appear, there are three separate `executable' flags, and
	set-group-ID appears.

	No BUGS yet, perhaps because the code was new.

Notice how history repeats: 4e replaced the free-block bitmap with
a list, which made it simpler to cope with huge file systems but
harder to allocate blocks in a simpler order; sundry replacement
file systems in the early 1980s (Berkeley FFS, Weinberger's cheap
hacks in V8) restored the bitmap, because it's easier to pick a good
block when you can see all the blocks available, and because by then
computers had enough memory and disks were big enough that a large
bitmap wasn't a burden.

An anecdote may be (barely) relevant here.  I remember once in the
late 1980s having a chat with Lee McMahon about group IDs, and how
they didn't seem to have done quite what people wanted (hence the
multiple-groups-per-process stuff in most current systems, and the
special semantics for the set-group-id flag on directories, and
various other features that have seemed to me never to quite hit
the mark).  Lee told me that when Ken first put group IDs into the
system, he asked Ken what they were for.  Ken allegedly shrugged
and said `I dunno.'

Norman Wilson

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA15137
	for pups-liszt; Thu, 21 Jan 1999 03:49:52 +1100 (EST)