It's of value to have a little real magic in magic...

How to Add your Own ACPs ahead of the DEC ones

1. Steal FDT entries to get the operations you're interested
	in; stuff like open, extend, delete, close can all be
	quickly isolated as separate FDT entries. There are 
	proposed standards (Jon Pinkley & me) on how to steal
	these.
2. Once in an FDT you have to save the regs somewhere (allocate
	your own area) for later and put the process to sleep
	so it can't clobber its args while your daemon runs.
	RMS will do this if you don't stop it. RWAST the
	process & inhibit ASTs.
3. Send a message to your daemon that will do all the work to
	get it going, telling it what you want. You can use
	exe$writembx or any of several other signal methods.
4. Do intermediate $qio return and let the daemon do its thing.
5. When the daemon wants to continue the operation, have it
	send a special kernel AST to the original process (gets
	back to IPL ASTDEL and right process) and restore regs
	from your structure and continue the FDT loop, possibly
	lower down the kernel stack (FDTs need only a CALL frame
	and a JSB frame on stack); the code fragment in
	sysqioreq.mar is short 'n' sweet.
6. Return, having un-rwasted the process and reenabled AST delivery
	somewhere, since the user I/O gets reissued at the time
	of continuing the original FDTs. (Reenable ASTs before 
	continuing FDTs and un-RWAST the process then too...so the
	next time your loop to check if it should stay rwast'd
	runs the process will continue.)

Daemons can do lots of interesting things for you...like for instance
grabbing files off tape and putting back on disk. I'll leave other
possibilities as exercises for the reader (with some broad hints in
some of the docs I put on the S92 sig tapes.)

I should also mention there are a number of major enhancements to
this flow possible, but too intricate to describe the pitfalls
in a short presentation. This one does work, though; I've done it
as a test case.





--------------------------------------------------------------

How to make Virtual Disks Cluster Known

All it takes to make virtual disks known to a cluster as
cluster devices, so each node accesses a drive via its own
driver instead of using the MSCP server, is 2 things:

1. Set the dev$v_clu bit in the UCB DEVCHAR2 longword (at driver
	load time!)
and
2. Set an allocation class that's unique into the DDB (again at
	driver load time). As long as the underlying storage is
	the same across a cluster (which can be because you were
	careful to use the same container storage on all nodes
	you loaded the driver, or because the driver or process
	that associates storage with a device checks), the
	device will work as a common disk.

	I did this with a VD drive so I had $193$vda0: known around
	a cluster, using a container that was on a local drive
	on one of the nodes and was available via MSCP server
	on the others. The I/O went directly to the VD driver
	on each node (so the VD driver's processing was purely
	local), then to the underlying disk (direct or via MSCP).
	Knowing SCS or MSCP is NOT necessary to get this to work.

	This is fairly useless for VD since the local processing is
	completely trivial. On a striping driver, it is more useful,
	and where the target storage is on HSCs it makes more sense
	to do virtual disks this way than to mount a VD on one node
	and MSCP serve that to the cluster...you eliminate the MSCP
	server and the critical node. It is also a TRIVIAL mod to
	a driver. (My striping driver has facilities to check that
	the storage is really the same BTW; doing this with VDdriver
	as I have VDdriver requires user care.)