On Jul 15, 2019, at 7:48 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2019-07-15 17:36, John Forecast wrote:
On Jul
14, 2019, at 11:55 PM, Thomas DeBellis <tommytimesharing at
gmail.com
<mailto:tommytimesharing at gmail.com>> wrote:
However, there was a pretty vast commonality in the RSX code base. Specifically, I was
wondering about two things:
Yes and no. Application level code was usually pretty
easy to get running on all flavors of RSX-11. However, the internal architecture was split
into 2 classes:
1. RSX-11D/IAS - mapped systems only
Device drivers ran as ?tasks? (processes) with direct access to I/O devices, system
memory allocations and some system routines
Not only that. Device drivers were expected to manipulate event flags of other tasks
directly, and then inform the OS that a significant even happened, which could force
rescheduling of tasks. And it seems every driver had the code to do this work inline in
the driver. So all kind of I/O completion becomes sortof messy. I think the driver is
still expected to switch to kernel mode before doing this work, and also copy the IOSB
data to the requesting task. Not sure exactly how a think like a swapped out process was
handled in this case, but maybe the task was always locked in memory if I/O was active.
2. RSX-11M/11S - any PDP-11 system with
sufficient memory + devices
Device drivers ran as part of the ?kernel? serialized by the fork block mechanism
Right. And I/O completion is normally handled by a couple of routines in the kernel, so
the driver itself can be pretty minimal.
I guess RSX-11M+ could be consider a separate
class adding I/D space, supervisor mode and multi-processor support.
Nah. 11M+ is really very similar to 11M. They pretty much share the same codebase, but M+
extends some data structures with a bit more information, and also adds a couple of more
structures to make the system more flexible.
The splitting of I/D space, as well as supervisor mode actually have very little impact
on the kernel. There is obviously a bit more work at a context switch, and there are a
couple of details around ASTs, which can switch between user and supervisor, but much of
the rest don't know or care. And drivers can pretty much be moved straight over,
although you normally would want to modify them to take advantage of some nifty additional
capabilities provided by M+.
There were a lot of small changes throughout the networking code to get it running
on our dual-processor. We eventually shipped with the kernel networking code running with
cache bypass enabled and the intention of revisiting it in a later release. One the 11/74
was cancelled, we were never given the opportunity?
1. What is the latest Phase DECnet that 11M will run?
I guess the
last release was 93?
Phase IV. The last release I see on
bitsavers.org
<http://bitsaver.org> was 4.5 in Oct 1989
No. Last/latest release was in 1998/1999 (depends on whether you look at 11M or 11M+).
But it was still all just phase IV.
Latest 11M is V4.8, and latest 11M+ is V4.6.
I think they are even available to trailing-edge?
That?s the base 11M/11M+ distribution? Do you know if there was a corresponding
DECnet release?
John.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol