When googling for File System Switch or Virtual File System most sources mention Sun NFS and SysVr3 as the earliest implementations. Some sources mention 8th Edition.
I did a (short) search on FSS/VFS in earlier, non-Unix OS’s (Tenex, Multics, CTSS, etc.), but none of those seem to have had a comparable concept.
Does anybody recall prior art (prior to 1984) in this area?
Paul
All, I just received this e-mail from a non-TUHS list member. If you have
an answer for Michael, could you reply to him and pop a cc here as well?
Thanks, Warren
----- Forwarded message from Michael Siegel <msi(a)malbolge.net> -----
Date: Sun, 14 Jun 2020 16:37:59 +0200
From: Michael Siegel <msi(a)malbolge.net>
To: wkt(a)tuhs.org
Subject: Origins and life of the pg pager
Hi there,
I'm trying to find out where the pg pager originated.
The research I've done so far vaguely suggests it came with one of the
System V versions, though Internet claims it to be “the name of the
historical utility on BSD UNIX systems” occasionally.[1]
I think System V because the source code of pg.c in the util-linux
package says that this utility is “a clone of the System V CRT paging
utility.”[2]
I'd also like to find out when pg was discarded and if it ever made it
into POSIX before that. Linux still has pg to the very day, but none of
the current major BSDs (Free/Net/Open) offer it. POSIX 2001, 2004
Edition lists it as an excluded utility.[3] I've not been able to get
the text of any prior POSIX documents. It seems they aren't freely
available.
Any ideas on how to proceed?
Best
Michael
[1] This one's from Wikipedia (https://en.wikipedia.org/wiki/Pg_(Unix))
but I've also found other sites stating the same.
[2]
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/text-ut…
[3] https://pubs.opengroup.org/onlinepubs/009696899/xrat/xcu_chap04.html
----- End forwarded message -----
Could someone point me to some information about s editor?
Googling didn't help
On Fri, Jul 3, 2020, 9:00 PM <tuhs-request(a)minnie.tuhs.org wrote:
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> or, via email, send a message with subject or body 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-owner(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TUHS digest..."
>
>
> Today's Topics:
>
> 1. v7 uucp debugging help requested (Adam Thornton)
> 2. Re: v7 uucp debugging help requested (Clem Cole)
> 3. Re: v7 uucp debugging help requested (Grant Taylor)
> 4. Re: v7 uucp debugging help requested (John Cowan)
> 5. Re: v7 uucp debugging help requested (Clem Cole)
> 6. Re: v7 uucp debugging help requested (Clem Cole)
> 7. Re: v7 uucp debugging help requested (Norman Wilson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 3 Jul 2020 13:52:42 -0700
> From: Adam Thornton <athornton(a)gmail.com>
> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
> Subject: [TUHS] v7 uucp debugging help requested
> Message-ID:
> <CAP2nic3UNxqi-obHwB5H+Ee+x5MKsd=eBrwhVbX+Ao3AgVPx=
> g(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> (if this is better suited for COFF, that'd be fine too)
>
> I've been trying to set up UUCP on my V7 system and its raspberry Pi host.
> This plus the "s" editor (already working) are really all that's needed to
> make this something pretty close to a daily driver, if all I wanted to do
> was write text files (which in some sense is all my job _is_, but to be
> fair I get a much more immediate feedback loop in my current environment).
>
> I was following
>
> https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Insta…
> more or less--I had already rebuilt v7 with the DZ terminal driver and was
> using it for interactive sessions (albeit, before I started trying to get
> UUCP running, with 7-bit line discipline--but I've since changed that).
>
> I have 16 DZ lines, I've set them to 8-bit mode. They're working fine,
> because I can use them for terminal sessions.
>
> I've built UUCP, set a node name, and set it up on the pi.
>
> I can execute uucico to send files, and it, frustratingly, almost works.
>
> >From the Pi side, I see (with uulog):
>
> uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol
> 'g' sending packet/window 64/3 receiving 64/7)
> uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
> /home/adam/git/simh/sim_scsi.h (6780 bytes)
> uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for
> packet
> uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86,
> resent 6, received 1
> uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
> order 0, remote rejects 0
> uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440
> bytes 19 bps)
>
> So it's clearly logging in, and if I telnet in directly, the v7 end is
> starting uucico as expected:
>
> login: pi-uucp
> Password:
> Shere
>
> uulog -x on the v7 side has no output, and nothing ever appears in the
> spool directory, which I suspect is a direct result of the timeout waiting
> for packet.
>
> So my question is, what else do I do to debug this? Clearly the pi (Taylor
> UUCP) side is expecting something else--maybe an acknowledgement?--from the
> v7 side to let it know the transmission was successful.
>
> Any help would be appreciated.
>
> Adam
>
Grant Taylor:
I'm a little surprised that you're trying to use the 'g' protocol to
talk to v7. I thought the 'g' protocol came out later for TCP over
Ethernet connections. As such I wonder if UUCP on v7 supports the 'g'
protocol.
=====
You're mis-remembering. g was the original protocol,
intended for use over possibly-noisy serial lines (e.g.
modems on POTS). It does error checking of various
sorts with retransmission. I believe it is named g
after the protocol's original designer, Greg Chesson.
Later protocols meant to work over reliable, error-
checked links like a TCP/IP circuit were t and e.
Norman Wilson
Toronto ON
Date: Wed, 24 Jun 2020 14:31:34 -0400 (EDT)
From: norman(a)oclsc.org (Norman Wilson)
> Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison.
> Norman Wilson Toronto ON
I am still digesting all the inputs (thanks, all!)
The above post made me realise that the delineation of what is a FSS/VFS or not, is not so easy.
I did a little bit of reading, and the concept of an ACP arrived with RSX11D in May 1973, but only matured in RSX11M in November 1974. As I understand it, originally in RSX11 file system code was closely tied to the low-level device driver for each device. ACP’s separated the file system code from the device driver itself, and became separate processes.
In essence there were two switches: one switch into abstract devices, implemented in ACP code and one kernel switch to deal with hardware interfacing. The first is indeed like a file system switch (although still tied to specific devices).
Looking at this stuff made me realise that my retro machine of choice (the TI990) went through a similar evolution. In the early seventies it had a sort of abstract device switch that linked to individual ‘device service routines’ (drivers). Initially, these modelled batch oriented ‘logical units’ that tied to files at the job control level. Later (late 70’s), the ‘open’ command would carry a file name and the file system was delegated to the device service routine. Still later (say 1983) this was used for networked disks.
As several people have observed in this topic, indeed there appears to be a close relationship between a device switch and a file system switch.
Anybody on the list know much about the provenance of SVr4 and OKIX for the
Okistation 7300 model 30?
http://museum.ipsj.or.jp/en/computer/work/0029.html indicates that OKIX
came later on the model 75, but many years ago as a staff programmer at
Oregon Graduate Institute, a surplus 7300/30 followed me home, but the
sysadmins referred to it as OKIX.
if anybody's interested in the hardware to do some spelunking, email me
off-list.
--
Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com
"The price of reliability is the pursuit of the utmost simplicity. It
is a price which the very rich find most hard to pay." -- Tony Hoare
> From: Rob Gingell
> RSEXEC (Resource Sharing EXEC) done on TENEX earlier in the 1970s.
That was associated with the National Software Works project:
https://apps.dtic.mil/dtic/tr/fulltext/u2/a132320.pdf
I think? (It's been four decades since I looked at NSW, so I don't recall
much about it.) Neither was TENEX-specific; e.g. there were Multics
implementations of RSEXEC and NSW.
Noel
> From: Richard Salz
> A web search for "its mldev" finds several things (mostly by Lars
> Brinkhoff it seems)
Yeah, other than the source:
https://github.com/PDP-10/its/blob/master/src/sysen2/mldev.106
there's not a lot on it.
That's typical of a lot of the innovative work done at the AI Lab, LCS, etc;
they built some extraordinary tools, but to them they were just tools they
used to work on their research, their _real_ work. So why bother to write that
stuff up? So people who actually used them remember them, but other than
that...
Welcome to tomorrow, where everything gets re-invented, because everyone is too
busy to waste time learning about the past.
Noel
> From: "Greg A. Woods"
> as Organick said in his 1972 book
A word of warning: i) Organick describes Multics as it was planned, not as it
was actually implemented; and ii) then it changed considerably during its
service life.
Examples of each: i) there was one linkage segment per processs, not per
segment (linkage info was copied across into the shared linkage segment when a
segment was dynamically added to a process' address space); ii) the New Storage
System.
The basic concepts (single level store, dynamic linking etc) are correct in
Organick, but be wary of anything past that. Not his fault, of course; things
just changed.
> As far as I can remember Multics didn't really have the concept of a
> "mount point".
In the original design, no. In 1973-75, with the New Storage System:
https://multicians.org/nss.html
mountable volumes were added (see MTB 229, "Use of Demountable Logical
Volumes", linked from the page above). It was released to customers in
June, 1976.
Noel
Reaching outside of UNIX, RSX/11 used external
supervisor-mode processes called ACPs (ancillary
control processes) to implement file systems.
I don't know exactly how they were plugged in,
but I do know they were pluggable, so their
interface must have constituted a file-system
switch of some sort. RSX dates back into the
1970s.
At some point in the latter part of the 1980s,
Ralph Stamerjohn (a name instantly recognizable
in the 16-bit DEC software world) gave a DECUS
talk about implementing a remote file system
through ACPs: a stub ACP on the client exporting
RPCs over the network, a real one at the server
end. I remember chatting with him about how
that did and didn't resemble the way pjw had
done it; interesting architectural comparison.
Norman Wilson
Toronto ON
> From: Anthony Martin
> wherein they state the following:
> A virtual file system, from the viewpoint of application programs on a
> computer, models the file system functions of other computers. This is
> done in the same way as with virtual terminals, a virtual file system
> consists of a UPP having virtual files (VF), and a UCP which executes
> virtual file system protocols.
> I'd be interested if you find anything earlier.
MLDEV on ITS would, I think, fit under that description.
I don't know if there's a paper on it; it's mid-70's.
Noel
> From: Dave Horsfall <dave(a)horsfall.org>
> Ioctl: the Swiss Army knife of system calls. I thought it was a neat
> idea when it arrived (much better then those primitive stty/gtty calls)
> but now...
Like they say, when the only tool you have is a hammer...
Better syntax than stty/gtty, maybe but I'm not sure the semantics are that
much better. The problem is that, especially with devices, what the I/O
commands do is so widely varied that it's hard to fit them all under a
unified umbrella. Maybe some (e.g. asynchronous I/O), but not all.
Noel
There is an interesting paper that Dennis Ritchie and Dave Presotto wrote, “Interprocess Communication in the Ninth Edition Unix System” (https://www.bell-labs.com/usr/dmr/www/ipcpaper.html <https://www.bell-labs.com/usr/dmr/www/ipcpaper.html>).
This appears to be an update of a paper that they wrote in 1985, “Interprocess Communication in the Eighth Edition Unix System”. This earlier paper is hard to find.
Anybody on this list who has it on hand?
Rob Pike:
For my taste, the various Unix file system switches that I've seen are too
firmly tied to the idea of blocks and disks and all that, making them less
flexible than they should have been. That's why the Plan 9 version is about
names and byte streams, to make it as general as possible.
=====
The only file-system switch I know well is that in the later
Research systems. It has nothing to do with disks or blocks.
It is about names and inodes: turn name to struct inode, read
arbitrary chunk of data, write arbitrary chunk of data, create
file, unlink file, abominable ill-defined system call that just
wouldn't die erm I mean ioctl, and so on.
It was certainly a cheap hack (as its author cheerfully admitted)
but it really was about I/O operations, not about simulating
disks. That's why it so easily supported /proc (the one that
was just about processes, not the misnamed Linux one that
is really about all things in the kernel so you don't need
/dev/kmem).
I don't know a lot about later VFSes like those in SunOS or
Linux or the BSDs. Blockiness might well have crept in in
support of memory-mapped I/O or in collaboration with the
buffer-cache implementation. The Research version was never
used directly to support different on-disk file system formats
(we did a different pjw cheap hack for the one case that
mattered in the kernel, and used the idea later developed
more by FUSE for other cases because speed didn't matter).
Norman Wilson
Toronto ON
> From: Michael Siegel
> there's no need to write out "less" every time. You can just alias that
> to "pg" without causing any harm and save two letters, which is an
> improvement for a task that is performed manually rather often.
It always surpised me that there wasn't more of this - abbreviating the names
of the most-used commands, to minimize typing - or more specifically,
run-length encoding them based on how frequently they were used, with the
most-used ones given the shortest names.
The MIT-DSSR PWB1 system had a pager called just 'p' (source here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/p.c
if anyone wants to see it; the man page is dated Apr/77); and 'ls' was tweaked
to recognize the command name 'l' as an alias for 'ls -ls'.
Of course, aliases didn't exist in the shell back then, which was why the
command had to be coded to recognize the short form, and act differently.
(And /bin/l was linked to /bin/ls.)
'l' and 'p' are _still_ aliased in my shell,to this day!
> I hope it's okay that I chose to reply just to the list address and take
> all the other addresses out.
'That's not a bug, that's a feature!'
I always delete other addresses when replying to a list, unless I think someone
might not be subscribed to that list.
Noel
Hello All.
I have reconstituted Jon Bentley's DFORMAT preprocessor (troff and awk
source) and made it available on GitHub. See
https://github.com/arnoldrobbins/dformat.
This is an awk program that reads a description of data layouts, such
as registers or network packets, and generates PIC descriptions.
A Makefile generates PDF from the dformat.ms file using GNU troff.
Jon Bentley was helpful in the final stages, including contributing
his original files.
Enjoy!
Arnold Robbins
So in BSD family tree, there's a 2.9BSD-Seismo and a 2.9.1BSD listed.
Yet I can't seem to find them in the TUHS archive.
There is a 2.9-Patch directory dated 1985 the same as the date that's found
in the family tree. Is that the Seismo version?
And Kirk's archive has a 2.9pucc directory, which appears appears to be
from Purdue dated1987. How does this relate?
Thanks for any help you can provide
Warner
With some further reading and research (and the kind help of Heinz Lycklama and Jon Steinart) I’ve found that my understanding of early loop networks at Bell Labs confused several different systems. As far as I can currently tell there were at least 4 different loop networks developed around 1970 at Murray Hill.
1. The first one is the “Newhall Loop” (paper published in 1969). This loop used twisted pair cabling, ran at about 3Mhz and used variable sized messages. It seems to have used some sort of token to coordinate between hosts. This might have been the network that Ken Thompson recalled as having been in operation when he arrived at the labs in 1966.
2. The second one appears to have been the “Pierce Loop”, as described in 3 BSTJ papers submitted in 1970/71. This one was coax based, used T1 compatible frames and was used to connect H516 computers with various bits of equipment. It seems to have had a very short life span. Part of my confusion was that the term Pierce Loop also appears to have been used in a generic sense to denote loop networks with fixed-sized frames.
3. The third one is the “Weller Loop” (paper published in 1971). This loop used coax cabling, ran at 3.3Mhz and used fixed 35 bit frames/cells. Each cell carried one address byte and two data bytes. One participant on the loop was the controller and effectively polled the other stations. In its 1971 form it appears to have been for the H516’s only and was referred to as a “Serial I/O bus”. This is what Jon Steinhart was talking about.
The Weller loop was later redesigned (memo written in 1973) to interface with PDP-11’s as well. Heinz Lycklama used this loop in 1974 to connect several systems running (rump) Unix - see his paper about peripheral Unix here:
https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… <https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…>
This Serial I/O bus remained in use for several years at least.
4. The fourth and best known one is the “Spider Loop” (memo published in 1974, but operational from 1972). Twisted pair cabling, using T1 compatible frames. In use until about 1978. Main uses appear to have been the ‘nfs’ file store and the ‘npr’ remote printing service.
My conclusion from all that is that in 1974 Unix had access to two networks, Spider and the Serial I/O bus. For both, first experiments would have been in 1973. It is hard to be sure which one came first. If I had to venture a guess today, I’d say that Spider connected to Unix several months before the Weller loop (even though the 1st generation Weller loop preceded Spider). Maybe the conclusion is that both happened more or less in parallel: Weller was also one of the designers of the Spider hardware.
Hello!
I normally download items from the Society FTP site rather than from
the archival area on the website. And my clients kept getting bounced,
claiming that I should stop trying to connect frequently. Oddly enough
that was not the case a while ago. Was the archive recently updated
regarding hosting software?
On Windows it was FileZilla, and spun down to one rather than eight or
ten. And on the WSL SLES12 SP3 arrangement it was ncftp. Now
downloading the reports to go along with the one Paul made available
from the location is not important for today, I can wait until
tomorrow or the next day.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
Rob Pike:
Yeah, p is all we need. I think it originated with td at UofT. I might have
brought it with me to Bell Labs, or recreated it. Probably the former.
====
The former, I think. The source code in V10 is very similar
to that you left behind at Caltech (where I first encountered
p). Most differences have to do with using opendir and readdir
rather than reading raw directories in the SPname code.
A further clue is that, even in V10, p.c begins
/*%cc p.c pad.o spname.o
*/
The tool that looked for such lines to tell it how to compile
things (I forget its name; was it comp?) doesn't seem to have
survived in the archival backup I have from Caltech HEP, but
I'm quite sure it came from U of T as well.
Norman Wilson
Toronto ON
> less(1) was actually an improvement
Hmm. Less is my favorite whipping boy for featuritis.
% less --help |wc
242 1331 12202
I am very happy with p.
Doug
The C in v7 is, canonically, the language described in K&R, right?
I must be doing something dumb.
I am getting Webb Miller’s “s” editor built there, and I am down to one function.
/* chop_arg - chop a function's argument to a maximum length */
static chop_arg(fcn, arg, maxlen)
int (*fcn)();
int maxlen;
char *arg;
{
char save;
save = arg[maxlen];
arg[maxlen] = '\0';
fcn(arg);
arg[maxlen] = save;
}
This doesn’t like the function pointer.
$ cc -c choparg.c
choparg.c:11: Call of non-function
So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7?
Adam
