Some additional notes on stealing I/O flows:
Remember that when FDT processes are going, they expect the
kernel stack to contain a CALLG or CALLS frame and a JSB
frame on the stack. There can be other stuff you have above
that, just so those are present...a consideration that makes
it simpler to continue FDTs, or to appear to do so where
you've gotten into an "fdt" context in a nonstandard way.
You can get into such a context on your own with a user
service or the like (see Andy Pavlin's new Ethermon for
an example) of course. Nothing prevents you from having your
own code that communicates with drivers. The code in
SYSQIOREQ.MAR shows what drivers expect (which is very
little ... a correct IRP and registers set properly).

If one is going to call one's own daemons, looking at how the
IRPs are dismissed for XQP/ACP processing is useful.

As for modifying any security related process characteristics,
note that an authentication function is all one needs. If one
has a function
  authenticate(File ID, security info, secret_key) where the
key can be entered by a priv'd operation, that's all one
needs. An ACE could carry security info that such a function
could operate on which would inhibit forgery or reuse of 
these ACEs.

  Systemwide information can conveniently be placed in a
variety of places:
  * Inside a logical name
  * In a lock value block
  * In a driver's data (where the driver must not mess with it
	unexpectedly...a virtual driver is simplest)
  * Based off customer reserved cells.

All but the last can be done rather easily without worrying
about a cell being used already. The last unfortunately can
easily be collided with...lots of applications use those
same cells for incompatible things.

Stealing FDT or other entries must be done VERY carefully of
course, particularly if one wants to put things back.
IPL 31 is helpful but only on a uniprocessor.
   On anything else, care should be exercised. It's
best generally to have the linkage changed by a single 
instruction to a new address; the driver dispatch table
is practically made for this. Patching driver code on
the other hand is desirable seldom or never; it makes
your code too vulnerable to every mod DEC makes to its'
code. (Such code should at least check that the instructions
being bashed are what it expects. Not all of it does...)

Some of the issues in FDT stealing are that one must guard against
the application doing anything else while you add delay. Putting
the process in RWAST can be used to get around this, just so
your routine gets out at the right time. This also doesn't
screw up other waits that the application may be doing. (RMS
does reuse argument space.) Be sure not to mess up any registers
in doing this. Care is also needed in previous mode, since
any internal IRPs will probably be kernel and their mode
byte needs to be correct for kernel use, and the previous mode
(checked by PROBE instructions) at the time of issue needs
to be correct to get at any internal arguments. The previous
mode for the user's I/O must be right too, or a security hole
opens; checking for mode access is done in DEC FDT routines.
(IRP$B_RMOD should have the kernel mode field set if that's
the mode of the IRP.)