Here's a new version of the RAMDRIVER I wrote a while ago with lots better
performance than DEC's PDDRIVER.  This version has a fix in it for executing
certain images off of a "disk" controlled by the RAMDRIVER:  in the previous
version, a pathological case existed where a process incurring a page fault
executing at IPL$_ASTDEL would hang waiting for the RAMDRIVER to satisfy the
page fault read, since RAMDRIVER queues ASTs to processes.  This is a classic
deadlock.  This showed up during image activation a lot.  Additionally, if
the process in question owned a MUTEX, then slowly but surely the whole system
would hang waiting for the deadlocked process to release the MUTEX.  This also
happened a lot during image activation :-(

The new version doesn't suffer from this problem -- it bypasses queueing the
AST for page fault reads (or writes, for that matter, though why anyone would
set up a pagefile on a ramdisk is a bit beyond me), thus preventing the hangs.

The driver source, a program to set the size of the ramdisk, this text, the
text from my original Info-VAX posting from April 1988 and a command procedure
to build everything follows in VMS_SHARE format in 5 parts.

This version runs on VMS V5.x systems only.  If you're still running on V4.x
you're out of luck (you'll have to invent LDR$ALLOC_PT and LDR$DEALLOC_PT as
well as undo the spin lock stuff).

The last time I posted this I was deluged with questions about how to use it,
etc.  To short circuit that process this time, one uses the MAKE.COM procedure
to build it, and from a privileged account one does the following:

	$ Run SYS$SYSTEM:SYSGEN
	SYSGEN>  LOAD dev:[dir]RAMDRIVER
	SYSGEN>  CONNECT RDA0/NOADAPTER/DRIVER=RAMDRIVER
	SYSGEN>  ^Z
	$ Run INITVD
	Init-VD> RDA0: size-in-blocks
	$ Initialize RDA0: your-favorite-volume-label
	$ Mount RDA0: your-favorite-volume-label

and treat it just like any other disk.  The "blocks" for this disk come from
non-paged pool, and therefore you should ensure that you have enough non-paged
pool to accomodate the desired ramdisk.  Also, the RAMDRIVER uses system page
table entries to double-map I/O buffers for page fault reads -- this comes from
the SYSGEN parameter SPTREQ.  If there aren't enough free SPTEs then RAMDRIVER
will return error indications for page fault reads, rendering the process
incurring the page fault (and probably you, too) very unhappy.  I run the
VAXen here at SDSC with a fair amount of extra system address space (~1000
pages - but I have lots of spare memory) so this isn't a problem for me.

The upshot of this is:

	1.  Ensure you have enough non-paged pool.
	2.  Ensure you have enough SPTREQ.

before using RAMDRIVER.

I apologize for taking so long to fix this problem -- I've been aware of it
for quite some time.  RAMDRIVER is a spare-time project for me, and lately
my spare time has been measured in small integer numbers of micro-fortnights ...


As before, no warranty, expressed or implied.  Use at your own risk (I do).

Comments, fixes, etc.  welcome as always.