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.)
The paper I am thinking of (gee, I wish I could remember any other details
about it...) was *very* detailed and specific, and was hardware-specific
to either the PDP-11 or VAX. It would not at all be applicable to Linux
or any kind of modern OS.
I am wondering if it is something in the Leffler et al book, I'll have to
go back and review that. I'll have to find my copy of it first...
Scott Lee, who worked with me on the Georgia Tech Software Tools
Subystem for Pr1me Computers, recently unearthed two tapes with
some version of that software. These may be the only copies
| I was cleaning out the basement of my house. They're 35 years old, but
| they've never been left in the heat or anything. I opened one of them
| up and checked the tape and it's not self-sticky or anything. The odds
| that they're readable is slim, because old 9-track bits tended to bleed
| through each other. You were supposed to spin through the tape every
| couple of years to make them last longer. That's obviously not happened.
There was discussion here a while back about services that will
recover such tapes and so on. But I didn't save any of that information.
If you have information, PLEASE send it to me so that I can relay it
Dennis Boone & Bill Gunshannon (are you on this list?) - I may ask you
to contribute $$ towards this once I know more.
----- Forwarded message from meljmel-unix(a)yahoo.com -----
Thanks for your help. To my amazement in one day I received
8 requests for the documents you posted on the TUHS mailing
list for me. If you think it's appropriate you can post that
everything has been claimed. I will be mailing the Unix TMs
and other papers to Robert Swierczek <rmswierczek(a)gmail.com>
who said he will scan any one-of-a-kind items and make them
available to you and TUHS. The manuals/books will be going
to someone else who very much wanted them.
----- End forwarded message -----
This could've been avoided if there was a convention about
where to store per user per app settings & possibly state. On
one of my Unix machines I have over 200 dotfiles.
Some, I think including Ken and Dennis, might have argued
that real UNIX programs aren't complex enough to need
lots of configuration files.
Agree with it or not, that likely explains why the Research
stream never supplied a better convention about where to
store such files. I do remember some general debate in the
community (e.g. on netnews) about the matter back in the
early 1980s. One suggestion I recall was to move all the
files to subdirectory `$HOME/...'. Personally I think
$HOME/conf would have been better (though I lean toward
the view that very few programs should need such files
But by then BSD had spread the convention of leaving
`hidden' files in $HOME had spread too far to call
back. It wouldn't surprise me if some at Berkeley
would rather have moved to a cleaner convention, just
as the silly uucp-baud-rate flags were removed from
wc, but the cat was already out of the bag and too
hard to stuff back in.
On the Ubuntu Linux systems I help run these days, there
is a directory $HOME/.config. The tree within has 192
directories and 187 regular files. I have no idea what
all those files are for, but from the names, most are
from programs I may have run once years ago to test
something, or from programs I run occasionally but
have no context I care about saving. The whole tree
occupies almost six megabytes, which seems small
by current standards, but (as those on this list
certainly know) in the early 1980s it was possible
to run a complete multi-user UNIX system comfortably
from a single 2.5MB RK05 disk.
Dennis's `The UNIX I/O System' paper in Volume 2 of the 7/e
manual is basically about how drivers work. Is that near
enough, possibly as augmented by Ken's `UNIX Implementation'
paper in the same book?
Those were my own starting point, long ago, for understanding
how to write device drivers. Along with existing source code
as examples, of course, but (unlikely many who hack on device
drivers, I'm afraid) I have always preferred to have a proper
statement of rules, conventions, and interfaces rather than
just reading code and guessing.
I'm trying to find the predecessor to "Writing a UNIX Device Driver, J.
Egan & T. Teixeira, 1st ed, 1988". In the preface, it says:
"This book is based on a MASSCOMP manual, Guide to Writing a Unix Device
Driver. The first version that MASSCOMP published as part of the
documentation set for the MC-500 was based on preliminary drafts prepared
for MASSCOMP by Cliff Cary and Tom Albough of Creare R&D."
I checked bit keepers and found nothing.
I was wondering if people on this list know of this manual, have a copy,
etc. In general, I'm looking for pre-SysV driver manuals. I can find all
kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well),
but nothing for System III or V7 unix. There were a lot of early systems
that were based on ports of V7 to different architectures that were then
updated to System III or System V (at least according to the big chart of
unix history and some wikipedia entries, which may be just repeating
marketing schlock and not reflect actual reality).
As part of a talk I'm putting together on the 40th anniversary of V7, I
wanted to have a bit of history for things we still have in unix today
(like strategy) and things that successors to unix have added or left
behind (like the packet mux in V7 that was tossed aside for either STREAMS
or netinet from BSD, though packet muxing to userland is back with DPDK).
>From at least V2 to V6, the ls(1) command would not
show directory entries whose names began with a '.'
unless the -a flag was supplied.
This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.
All further versions of Research Unix retain the
convention of V7 and Plan 9 ultimately made it
unnecessary. However, BSD and its descendants did
not follow suit. Instead, they continued behaving
like V6 with an additional -A flag to emulate V7.
Was the initial behavior intentional or just a
matter of expediency?
Who made the change and what was their motivation?
Was it a reaction to the intentional hiding of what
came to be known as "dot files"?
> From: Arnold Skeeve
> If you have information, PLEASE send it to me so that I can relay it
> to Scott.
IMO, only one choice: Chuck Guzis (cclist(a)sydex.com); he's very active in the
vintage computer community, and reads old media professionally.
I've used him (to recover those backup tapes of the MIT PWB1 system), which
was rather tricky (bad mold; he had to build a special tool to remove it), and
I was incredibly happy. Very reasonable price too - although he may have given
me a special 'collector' rate.. :-)