>Johnny Billquist wrote:
>On 2014-01-01 14:19, Jerome H. Fine wrote:
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't
normally do that just to bring devices offline or online. That is a
separate operation from loading and unloading device drivers. But yes,
if you want to disconnect devices, buses, CPUs or memory, you can do
that just fine on a running RSX system. And bring them online again
later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
Yes. That is correct. You can load and unload device drivers at runtime. That is actually a very important design feature in RSX.
So your understanding about RSX have been totally wrong.
Device drivers that are currently in use can not be unloaded, however. Which means that the boot device can't be unloaded, for instance.
YES!! RT-11 has the same requirement. Sort of obvious to
anyone who actually uses the operating system.
In M+ the ability is even better, as device driver loading and unloading is not related to devices being online or offline.
RT-11 has the same ability. A hard drive can be online
without the device driver being LOADed. If a background
program requests access to a drive, the program can perform
a temporary .FETCH to bring the device driver into memory
and then .RELEASE the device driver when finished. A system
job can't request RT-11 to perform a FETCH, so any disk
drive needed by the program must have the device driver
LOADed before the program uses the disk drive. In theory,
a system job could pause and the user could then LOAD
the device driver just before the system job uses it. MACRO-11
always attempts a .FETCH when a device driver is not already
LOADed.
One aspect of the FETCH is that for a Mapped version of
RT-11, the code can be placed in an address which is not
allowed for LOADed device drivers. This often takes place
when a background job is executed as a virtual job under
the program VBGEXE and the Low Memory from 1000
octal to 40000 octal is then available. At least a stub of
all device drivers much be in Low Memory even if the
device driver also uses Extended Memory (one of the
other things that INSTALL does is to set up the Extended
Memory portion of any device driver).
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit online of a device is done when you load it, and offline is done on a device before unloading it. In M+ the offline and online steps are separate commands, which just requires that a device driver is loaded.
In RT-11, a device driver must be INSTALLed and the
name placed into the Permanent Physical Device Table
before a LOAD can be performed. The INSTALL code
checks that the device driver is compatible with the
operating system parameters, among other things. A
user may then UNLOAD and REMOVE (in that order)
a device driver if a different version of the device driver
is needed, such as for testing a new version.
Even more fun is M+ is that device drivers do not need to be recompiled if you recompile the kernel. Device drivers are totally independent of the kernel.
Likewise in RT-11. In fact, I believe RT-11 has always
been that way.
Also, file systems are also separate, and handled by something called an ACP, which is a separate task. This means that you can have different types of file systems on different disks.
ACPs hook into device drivers, but device drivers have no clue about ACPs.
Not available in RT-11 except maybe as part of the actual
user program.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
TSX-Plus is similar. All device drivers must be LOADed and
permanently resident at boot time.
Jerome Fine
From: "Lee Gleason" <lee.gleason at comcast.net>
multiple Unibuses (Unibusen? Unibeese?)
"Unibi".
The
user asks, "Why Hercules?". Brian said that it took a Hercules to wrestle
the three headed dog that was the device configuration databases involved
into submission.
Nice. Well I guess if TGHA makes sense ("The Great Heuristic Algorithm" --
um, for spare columns in ECC memory, right?), this makes a lot more sense...
John Wilson
D Bit
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
RSTS doesn't have loadable drivers, so it all has to be genned into the
system (and user-written drivers aren't officially supported). On the plus
side, RSTS autosizes the system on every boot (including floating CSRs, and
all vectors except card readers are autodetected so they don't need to follow
the rules at all -- user-written drivers would have to be hooked up to this
too), and passes CSR/vector/model information to the drivers that it enables.
So while RSTS requires the drivers to be linked to the system, it's not a
totally rigid mass that works only on the exact config it was built for.
You can run a monitor on totally different hardware and as long as it has
drivers for enough of the existing peripherals to work, you're all set.
Also, you can have multiple monitors (built different ways) on the same
pack and tell the pre-boot thingy (INIT.SYS) which one to boot.
John Wilson
D Bit
On the 11/74 you more or less had this, in the form of hotplugging whole bus segments. One a bus segment was disconnected, you could power it off, and remove controllers if you wanted.
This reminds me of a conversation I overheard at an RSX Magic Session, at a DECUS symposium in the 80s. A customer was asking Brian McCarthy, a noted RSX developer, a lot of questions about the legendary 11/74 and the RSX11M+ additions that had been made to support it. They were discussing the multiple Unibuses (Unibusen? Unibeese?) and the software that controls them. The user pointed out that the three letter task name for the Host Reconfiguration Task (HRC...) was a little tortured - it would have made more sense to be HRT. Brian said that internally they had called it Hercules, and HRC was the three letter abbreviation they chose for it. The user asks, "Why Hercules?". Brian said that it took a Hercules to wrestle the three headed dog that was the device configuration databases involved into submission.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
On 2014-01-01 14:19, Jerome H. Fine wrote:
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't
normally do that just to bring devices offline or online. That is a
separate operation from loading and unloading device drivers. But yes,
if you want to disconnect devices, buses, CPUs or memory, you can do
that just fine on a running RSX system. And bring them online again
later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
Yes. That is correct. You can load and unload device drivers at runtime. That is actually a very important design feature in RSX.
So your understanding about RSX have been totally wrong.
Device drivers that are currently in use can not be unloaded, however. Which means that the boot device can't be unloaded, for instance.
In M+ the ability is even better, as device driver loading and unloading is not related to devices being online or offline.
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit online of a device is done when you load it, and offline is done on a device before unloading it. In M+ the offline and online steps are separate commands, which just requires that a device driver is loaded.
Even more fun is M+ is that device drivers do not need to be recompiled if you recompile the kernel. Device drivers are totally independent of the kernel.
Also, file systems are also separate, and handled by something called an ACP, which is a separate task. This means that you can have different types of file systems on different disks.
ACPs hook into device drivers, but device drivers have no clue about ACPs.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
Johnny
>Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do that just to bring devices offline or online. That is a separate operation from loading and unloading device drivers. But yes, if you want to disconnect devices, buses, CPUs or memory, you can do that just fine on a running RSX system. And bring them online again later, if you want to. Any other trick you'd like to do? :-)
While it is extremely unlikely that I will ever run RSX-11, the
above ability surprises me. Please clarify to make sure that
I understand. It is my impression that RSX-11 requires
all device drivers to be LOADed at boot time and always
be kept LOADed. TSX-Plus has this requirement and I
guess I assumed that RSX-11 was similar.
Based on your information, I understand that RSX-11 does
support a device driver UNLOAD and REMOVE commands
(or whatever syntax is used in RSX-11 since I just used the
RT-11 syntax). So please confirm.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
Jerome Fine
On 2014-01-01 08:33, Cory Smelosky wrote:
On Wed, 1 Jan 2014, Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do
that just to bring devices offline or online. That is a separate operation
from loading and unloading device drivers. But yes, if you want to disconnect
devices, buses, CPUs or memory, you can do that just fine on a running RSX
system. And bring them online again later, if you want to. Any other trick
you'd like to do? :-)
Now if only UNIBUS hotplug/hotremove existed. ;)
On the 11/74 you more or less had this, in the form of hotplugging whole bus segments. One a bus segment was disconnected, you could power it off, and remove controllers if you wanted.
Johnny
From: Cory Smelosky <b4 at gewt.net>
Now if only UNIBUS hotplug/hotremove existed. ;)
Officially, it does (if you have a DT03 or DT07 bus switch).
Pretty rare though...
John Wilson
D Bit
On Wed, 1 Jan 2014, Johnny Billquist wrote:
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do
that just to bring devices offline or online. That is a separate operation
from loading and unloading device drivers. But yes, if you want to disconnect
devices, buses, CPUs or memory, you can do that just fine on a running RSX
system. And bring them online again later, if you want to. Any other trick
you'd like to do? :-)
Now if only UNIBUS hotplug/hotremove existed. ;)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-01-01 00:52, Jerome H. Fine wrote:
>John Wilson wrote:
The order of dependence on strictly working (and/or accurately emulated)
hardware goes: RT => RSX => RSTS. So the fact that something works
with RT proves *nothing*! (I've learned this the hard way so many
times.)
Of course, looked at another way, it's nice of RT to be willing to run
on hardware that's not long for this world...
... OR the CSR for the hardware and the device driver do not
match. Fortunately, RT-11 allows the user to change the
CSR after the boot (for a data device obviously). After that,
the user can INSTALL and LOAD.
RT-11 also supports UNLOAD and REMOVE if a user
needs to power down a data hard drive and physically replace
that drive with a different hard drive. This is really especially
helpful with MSCP devices. If the user has ONLY the single
controller to boot RT-11, VM: can be used to hold the few
essential files required by the operating system. At that point,
the hard drive on an MSCP device can have the power
and cable removed (after the RT-11 UNLOAD and REMOVE)
and a different hard drive substituted (followed by the RT-11
INSTALL and LOAD commands). Try doing that on RSX-11
or RSTS/E.
RSX can boot from virtual devices.
Also, you can load and unload device drivers in RSX, but you don't normally do that just to bring devices offline or online. That is a separate operation from loading and unloading device drivers. But yes, if you want to disconnect devices, buses, CPUs or memory, you can do that just fine on a running RSX system. And bring them online again later, if you want to. Any other trick you'd like to do? :-)
Johnny
