🚀 go-pugleaf

Re: Jon Pinkley's (kind) remarks about vddriver...
The latest & greatest was in fdvdkit.zoo in the S92 tapes in
[vax92a.gce92a.net92a]fdvdkit.zoo. Some later stuff and fqdriver.mar
(a somewhat better fddriver.mar version) are in that directory also
as separate files. Recent mods have mainly been in adding some new
device geometries to the assign - VD image and setting it up so
the device type gets set then instead of leaving dt$_FD1 in there
for all disks. I use VD: drivers all the time for testing file
structure hacks. It's also easy to change driver name to vdbdriver
so I have two layers of them with separate drivers when I want to
do weird hacking that involves munging driver tables. The lower
and unmodified driver makes sure the rest of my system's disk space
doesn't get scribbled on if something I do to a vdbdriver unit
causes it to start clobbering its unit. Since the size and geometry
of the VD: units can be easily controlled, I can be a little more
sure those can't have any effect on my stuff.
   The recent hacks that cover setting the allocation class in the
driver (thanks, Jon!) will be on the F92 tapes. They're real small
but might be handy.
   Still, floppies are also handy where I want a removable and
system-mountable device that I can test. I recently did a little hacking
on passing ownership of mounted volumes around. A short hack that
just changes the device owner UCB pointer does allow access, but
dismount requires the mounted volume list to be messed with, and
I haven't taken the time to find where that list header is to see
about moving it around. The little hack lets me say something like
$claimdevice devname:/pid:nnnnnnn  to move the ownership of devname:
to the process whose EPID is nnnnnnn, provided somebody else has
it privately owned already. I'll post it if anyone is interested.
Glenn
Everhart@Raxco.com