🚀 go-pugleaf

In answer to the original question: I can't see much wrong with the basic
structure of the $QIO service.  This is a separate question to whether
the drivers that one accesses through it are correctly designed, and indeed
whether they should be drivers at all. The QIO interface to the file system
is the most obviously inelegant one. Like Glenn, I'd like to see VMS support
more file-systems in a much more integrated way, perhaps via loadable
filesystem drivers/XQPs/ACPs/whatever and documentation and support for
writing them.

Back to $QIO, the interface is a lot more powerful than a lot of folks
realize. Itemlist IOs are just scratching the surface of what is possible.
I once write a driver with an  embedded interpreter, which  executed
instructions, including conditionals and loops, read from a command
buffer passed as one of the arguments. In addition, the driver mapped the user's
data buffer with realime SPTs, and was capable of firing ASTs (other than
completion ASTs) at the issuing process. The way one used this was for
the driver to decide what an interrupt meant, to get vital data out of
hardware registers and into the user's buffer within interrupt-service-routine
latency, and then to AST the process to let it know that the data buffer
held some more data. The process-based code would eventually get to
execute (milliseconds later, but before the termination of the IO) and could
keep the user posted on what the hardware was doing, move data from the
IO buffer to disk, apply complicated numerical modelling to decide whether
to abort the IO... just about anything you wanted.

The hardware in question was a CAMAC crate. This driver structure permitted
a nonprivileged and non-expert programmer to program the handling of LAMs
(interrupts) with latencies of around 10 microseconds, without any risk
of crashing the system. (The interpreter couldn't be programmed to
access memory outside of the QIO'ed data buffer, and wouldn't interpret more
than a reasonable number of instructions between waits for interrupts, so
infinite loops at hardware IPL also couldn't happen).

I don't know whether these ideas could be useful other than for interfacing
to physics experiments, but the mere fact that it was possible says a lot
about how well thought out is the basic design of IO processing in VMS.

        Merry VAXmas,

                Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)