There are a number of techniques which don't get discussed a lot in
DECUS circles. Sometimes I wonder whether this happens because they
are too valuable and get used in commercial packages.
  Anyhow, having figured out some of them I propose to write a bit
about them here.
   In the main the ones I know of are techniques for stealing
information flows. You see these crudely in vddriver and
fddriver, where the drivers mess with IRPs and call other
parts of VMS from inside start-IO packets. (The old technique
in vddriver of starting in one set of FDT entries and switching
cleanly to another is also useful, though my drivers don't use it
anymore.) The scheme in fddriver to have a process do all real
work in doing disk I/O was also cute. Here the only real trick
was completing two I/O's at one time.
   One can go far by stealing IRP completions. You do this
by replacing irp$l_pid with a system address; it will be called
via JSB from the I/O post processing (ipl 4) processing. You
can of course replace the old irp$l_pid and recall the
completion, or use this as a way of calling a driver as if it
were a subroutine. Consider the merits of stealing the FDT entries
for the ctdriver in order to monitor what it's doing. You can
modify the IRP for a read to come back to your kernel code after
the read finishes, let the driver do its' thing, and then after
grabbing off a copy of the data go and replace the IRP field and
complete the I/O yourself (reqcom or the like).
   Other FDT stealing tricks are clear. Suppose you want to
extend the disk filesystem so files can be migrated around.
You can steal the FDT entries for a disk driver so that you
get control in your code on an open before the real DEC FDT
code does. You can queue a message to a daemon process then which
will do stuff like decompress or copy a file to the disk (if the
fdt is not called by the daemon of course), and it can then
send a special kernel ast to the original process which can be
made to start the DEC FDT code which will then find a normal
file. If your process finds the file someplace it wants to leave
it, all it needs to do is be willing to handle virtual I/O itself
(and get control on virtual I/O) and it can leave a file on
secondary storage. You can mark files with application ACLs to
store real locations on backing store, mark compress methods,
or the like, without screwing around with unused header info.
Once in the FDT routines, the IRP already exists and the
user mode code is already waiting if it likes for I/O
completion; no further synchronization of that is needed.
This amounts to allowing two (or more) ACPs per disk. Neat
stuff is possible with tricks like that.
   The irp$l_pid hook is in there and heavily used by MSCP code.
It is unlikely to go away.
   If you want a driver to work transparently with MSCP you can
of course structure it as a port driver rather than a normal
driver as vddriver and fddriver are.
   Then again by stealing a start_io entry point it's possible to
do things like disk caching. The tricky part is handling port
drivers as well as local ones. They also have a start_io vector
but its' format differs from the normal driver's since they use
the class driver. Similar stuff can be done for tape of course.
Paul Sorensen's CDDRIVER is an example of a caching system, but not for port
drivers.

	Glenn Everhart
	1/6/92

An application of this stuff might be encrypting files in place.
One could mark a file with a crypto checksum in an application ACE
to flag that it was encrypted and to allow a program to tell
when it was decrypted correctly. A second-acp process that gained
control on open could decrypt the file, using a key from somewhere.
(The somewhere might be a logical name, perhaps with the invisibility
bit set, or might be queried for by the process on open, or something)
and if the decrypted file had the correct crypto checksum (or maybe
just the right CRC; we only need to know it's the right key) the
file could be left decrypted on disk. (The initial decrypt probably
should be to a scratch area someplace, or may be just the checksum
need be computed...depends on the speed of the encryption.) Catching
the close FDT entry could re-encrypt the file; one might play games
with a daemon also as a back-up procedure in case of crashes, and
perhaps see if a driver i/o cancel entry could be added to alert the
daemon. The daemon could also check that the open was for exclusive
access and ensure that it only decrypted a file so opened, or force
the open to be exclusive access, so the file would be locked during
the time it was on disk in plaintext.
   Of course one can go further and have such a trap daemon just
handle the virtual I/O as well, decrypting blocks as they are read where
the open is just for read, or encrypting also on writes. Since one
then gains full control, such operation is straightforward and
leaves the disk based data always encrypted.
   This is similar to what a cryptodisk does in many respects, but
the files would still be on their original devices and would appear
to be normal, save that their contents were transparently garbled.
Decompression, or moving files online on demand from other media or
network sites, or the like are variations on the theme.
   One drawback is that the ACEs must be untouched and the DEC defragment
movefile primitive can occasionally screw these up. Therefore some
way to reconstitute lost ACEs needs to be present, or one needs to have
some other encoding someplace in the file header to flag what is to be
done. There are fortunately some bit combos in places like record
attributes that might be used, due to their never appearing in
real life. If one can ensure that the application ACE is the first
there, and is in the same block with the first header, though,
the ACE will be safe.
   Note that similar trapping techniques can be used to flag I/O has
happened. One could also use such techniques to dynamically prevent
file deletions (by causing the delete FDT entry to return an I/O error)
on a disk or re-enable them, or even to software writelock a disk
dynamically, though this is not necessary since the bit exists already
and can be toggled in the driver status word.
  I trust this has shown some of the fun and profit which one can have
with these sorts of techniques, and would like to invite discussion of
them, and solicit other ideas for Useful Hacks like these...
Glenn Everhart