> From: ron minnich <rminnich(a)gmail.com>
> To: TUHS main list <tuhs(a)minnie.tuhs.org>
> Subject: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and
> arcane")
> Message-ID:
> <CAP6exYJshbA5HxOJ_iM21Cs0Y4vGfLuFigXxh4WTeqbZreY8UA(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I always wondered who wrote this, anyone know? I have my suspicions but ...
>
> ".SH BUGS
> .I Ptrace
> is unique and arcane; it should be replaced with a special file which
> can be opened and read and written. The control functions could then
> be implemented with
> .IR ioctl (2)
> calls on this file. This would be simpler to understand and have much
> higher performance."
>
> it's interesting in the light of the later plan 9 proc interface.
>
> ron
The manual pages were not yet under SCCS, so the best time gap that I
can give you is that the above text was added between the release of
3BSD (Nov 1979) and 4.0BSD (Nov 1980). Most likely it was Bill Joy
that made that change.
Kirk McKusick
I always wondered who wrote this, anyone know? I have my suspicions but ...
".SH BUGS
.I Ptrace
is unique and arcane; it should be replaced with a special file which
can be opened and read and written. The control functions could then
be implemented with
.IR ioctl (2)
calls on this file. This would be simpler to understand and have much
higher performance."
it's interesting in the light of the later plan 9 proc interface.
ron
Hi All.
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
extant anywhere.
He says:
| 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
to Scott.
Dennis Boone & Bill Gunshannon (are you on this list?) - I may ask you
to contribute $$ towards this once I know more.
Thanks!
Arnold
> From: Andrew Warkentin
> Mach and the other kernels influenced by it basically destroyed the
> reputation of microkernels ... a simple read() of a disk file, which is
> a single kernel call on a monolithic kernel and usually two context
> switches on QNX, takes at least 8 context switches - client->VFS->disk
> FS->partition driver->disk driver and back again).
Hammer-nail syndrome.
When the only tool you have for creating separate subsystems is processes, you
wind up with a lot of processes. Who'd a thunk it.
A system with a segmented memory which allows subroutine calls from one subsystem
to another will have a lot less overhead. It does take hardware support to be
really efficient, though. The x86 processors had that support, until Intel dropped
it from the latest ones because nobody used it.
Excuse me while I go bang my head on a very hard wall until the pain stops.
Noel
This is an appeal to the few really-old-timers (i.e. who used the PDP-11/20
version of Unix) on the list to see if they remember _anything_ of the KS11
memory mapping unit used on that machine.
Next to nothing is known of the KS11. Dennis' page "Odd Comments and Strange
Doings in Unix":
https://www.bell-labs.com/usr/dmr/www/odd.html
has a story involving it (at the end), and that is all I've ever been able
to find out about it.
I don't expect documentation, but I am hoping someone will remember
_basically_ what it did. My original guess as to its functionality, from that
page, was that it's not part of the CPU, but a UNIBUS device, placed between
the UNIBUS leaving the CPU, and the rest of the the bus, which perhaps mapped
addresses around (and definitely limited user access to I/O page addresses).
It might also have mapped part of the UNIBUS space which the -11/20 CPU _can_
see (i.e. in the 0-56KB range) up to UNIBUS higher addresses, where 'extra'
memory is configured - but that's just a guess; but it is an example of the
kind of info I'd like to find out about it - just the briefest of high-level
descriptions would be an improvement on what little we have now!
On re-reading that page, I see it apparently supported some sort of
user/kernel mode distinction, which might have require a tie-in to the
CPU. (But not necessarily; if there was a flop in the KS11 which stored the
'CPU mode' bit, it might be automatically cleared on all interrupts. Not sure
how it would have handled traps, though.)
Even extremely dim memories will be an improvement on the blank canvas we
have now!
Noel
> From: Rudi Blom
> Probably already known, but to be sure Interesting options: MX11 -
> Memory Extension Option: this enabled the usage of 128 KW memory (18-bit
> addressing range)
Actually, I didn't know of that; something else to track down. Wrong list
for that, though.
Noel
Probably already known, but to be sure
Interesting options: MX11 - Memory Extension Option: this enabled the
usage of 128 KW memory (18-bit addressing range); KS11: this option
provided hardware memory protection, which the plain /20 lacked. Both
options were developed by the Digital CSS (Computer Special Systems).
http://hampage.hu/pdp-11/1120.html
PS the page listed below has a very nice picture of the 'two fathers
of UNIX" working on a PDP-11/20
http://hampage.hu/unix/unix1.html
Kevin Bowling:
The conference looks supremely uninteresting outside one WAFL talk to me.
====
That is, of course, a matter of opinion. Just from skimming
titles I see about two dozen talks of at least some interest
to me in the ATC program. And that's just ATC; I'm planning
to attend the Hot* workshops on Monday and Tuesday as well.
Of course I won't attend every one of those talks--some coincide
in time, some I'll miss because I get stuck in the hallway track.
And some will prove less interesting in practice, though others
that don't seem all that interesting in the program will likely
prove much better in person.
I've been attending USENIX ATC for decades, and although some
conferences have been meatier than others, I've never ended up
feeling the trip was a waste of time.
Perhaps us old farts just aren't as discriminating as you
youngsters.
That said, I think Kevin's question
Is there a way to participate [on the UNIX50 event] without attending Usenix ATC?
is a good one.
Norman Wilson
Toronto ON
Bud Lawson, long an expat living in Sweden, died yesterday. Not a
Unix person, he was, however, the originator of a characteristic Unix
programmer's idiom.
Using an idea adapted from Ken Knowlton, Bud invented the pointer-
chasing arrow operator that Dennis Ritchie adopted for C. I played
matchmaker. When Bud first proposed the "based storage" (pointer)
facility for PL/I, he used the well-established field(pointer)
notation. I introduced him to the pointer-chasing notation Knowlton
devised for L6. Knowlton, however, had no operator because he had only
single-letter identifiers. What we now write as a->b->c, Knowlton wrote
as abc. Appreciating the absence of parentheses, Bud came up with the
wonderfully intuitive pointer->field notation.
Doug
I came across Scott Taylor’s site which mentions his adventure with MtXinu (https://www.retrosys.net/) I had asked a few years ago (February 2017?) about locating a set
Of this to no avail, but thanks to Scott the binary set is now available.
ftp://ftp.mrynet.com/operatingsystems/Mach2.5/MtXinu-binary-dist/floppies/M…
There is some additional documentation to be found here.
ftp://ftp.mrynet.com/operatingsystems/Mach2.5/MtXinu-binary-dist/docs
The floppy drive like 386BSD is super weak and I had no luck with Qemu. VMWare worked fine to install. The VMDK will run on Qemu as low as 0.90 just fine.
I haven’t tried the networking at all, so I don’t know about adapters/protocol support. I’ve been using a serial line to uuencode stuff in & out but it’s been stable.