Re: Does anyone remember IAS?

From: Glenn Everhart (Everhart-nospam_at_gce.com)
Date: 07/20/03


Date: Sun, 20 Jul 2003 13:23:21 -0400

IAS was sysgenned from RSX11D compatible sources, and by V3 you
could generate IAS V3 or RSX11D V7 from the same kit. RSX11D was
interesting from an I/O point of view in that every driver was also
a task and had user mode code. You could concoct drivers that were
doing normal file level I/O on one side and talking as devices from
the other. This made it possible to concoct spooling drivers
that had all the file i/o overhead in a separate task from the
caller, and still have the i/o go thru the filesystem. Given the
pdp11 tightness of address space this was for some things a Godsend.
(I recall the early RT11 under RSX implementations for example.)

DCL was there, and the RSX11D and IAS privilege sets prefigured the
VMS set. (RSX11M had privileged or nonprivileged TT UCBs, nothing
else pretty much.) I suspect some of the 11D experience fed into the
VMS privilege set design, since they are not THAT close. Still, the idea
was there that an application that was allowed to do kernel mode
functions should not necessarily also be able to ignore file protections.

During the time RSX11D was around, DEC's common response to security was
to do what they could but claim "DEC software does not operate in a
hostile environment". Sounds odd today, but even then they were telling
it as it is, not attempting to claim protections they knew were not
fully reliable.

Glenn Everhart

w m r wrote:
> I used IAS back in late 70's.
>
> IIRC, it was a klunk that run under RSX-11D that added timesharing
> (dynamic priorities). It also came with DCL that converted the DCL
> commands to the equivalent RSX-style commands.
>
> I had it on an 11/70 with 1MB MOS memory, two RP07's. That was living
> high on the hog back then.
>
> We used it for graphics applications. We had a funky 3D vector-style
> graphics scope that plugged into the unibus, and DMA'd the phigs-like
> display list instructions from the PDP's memory. I wrote the driver
> for it and a low-level subroutine library.
>
> I think the manuals came in dark blue notebooks. The manual covers
> were white with a purple and red stripe on them. I chucked the few of
> them I had left out a couple years ago.
>
> Mike



Relevant Pages

  • [PATCH 19-rc1] Fix typos in /Documentation : U-Z
    ... when the underlying device was capable of handling the i/o in one shot. ... using dev->irq by the device driver to request for interrupt service ... The EMU10K2 chips have a DSP part which can be programmed to support ... -(This acticle does not deal with the overall functionality of the ...
    (Linux-Kernel)
  • Re: [PATCH 19-rc1] Fix typos in /Documentation : U-Z
    ... +iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e ... when the underlying device was capable of handling the i/o in one shot. ... using dev->irq by the device driver to request for interrupt service ... -(This acticle does not deal with the overall functionality of the ...
    (Linux-Kernel)
  • [PATCH 18-rc3] Fix typos in /Documentation : S
    ... Request flows seen by I/O schedulers ... cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. ... +interface will appear in a separate directory under cpufreq ... This drives supports all SMC ISA/MCA adapters. ...
    (Linux-Kernel)
  • Re: NdisProt and multiple handles to the same device
    ... opens. ... You could, for example, perform the read using asynchronous I/O. ... Considering changing the driver the way you are thinking suggests that you ... Now the default ndisprot implementation prevents this by preventing ...
    (microsoft.public.development.device.drivers)