home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / vmsnet / internal / 1701 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.9 KB
  1. Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
  2. From: SYSMGR@IPG.PH.KCL.AC.UK
  3. Newsgroups: vmsnet.internals
  4. Subject: re: call for half-baked ideas
  5. Message-ID: <2A2018AA_000797F8.009654981B40EB80$8_1@UK.AC.KCL.PH.IPG>
  6. Date: Fri, 18 DEC 92 20:04:38 BST
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 43
  10.  
  11. In answer to the original question: I can't see much wrong with the basic
  12. structure of the $QIO service.  This is a separate question to whether
  13. the drivers that one accesses through it are correctly designed, and indeed
  14. whether they should be drivers at all. The QIO interface to the file system
  15. is the most obviously inelegant one. Like Glenn, I'd like to see VMS support
  16. more file-systems in a much more integrated way, perhaps via loadable
  17. filesystem drivers/XQPs/ACPs/whatever and documentation and support for
  18. writing them.
  19.  
  20. Back to $QIO, the interface is a lot more powerful than a lot of folks
  21. realize. Itemlist IOs are just scratching the surface of what is possible.
  22. I once write a driver with an  embedded interpreter, which  executed
  23. instructions, including conditionals and loops, read from a command
  24. buffer passed as one of the arguments. In addition, the driver mapped the user's
  25. data buffer with realime SPTs, and was capable of firing ASTs (other than
  26. completion ASTs) at the issuing process. The way one used this was for
  27. the driver to decide what an interrupt meant, to get vital data out of
  28. hardware registers and into the user's buffer within interrupt-service-routine
  29. latency, and then to AST the process to let it know that the data buffer
  30. held some more data. The process-based code would eventually get to
  31. execute (milliseconds later, but before the termination of the IO) and could
  32. keep the user posted on what the hardware was doing, move data from the
  33. IO buffer to disk, apply complicated numerical modelling to decide whether
  34. to abort the IO... just about anything you wanted.
  35.  
  36. The hardware in question was a CAMAC crate. This driver structure permitted
  37. a nonprivileged and non-expert programmer to program the handling of LAMs
  38. (interrupts) with latencies of around 10 microseconds, without any risk
  39. of crashing the system. (The interpreter couldn't be programmed to
  40. access memory outside of the QIO'ed data buffer, and wouldn't interpret more
  41. than a reasonable number of instructions between waits for interrupts, so
  42. infinite loops at hardware IPL also couldn't happen).
  43.  
  44. I don't know whether these ideas could be useful other than for interfacing
  45. to physics experiments, but the mere fact that it was possible says a lot
  46. about how well thought out is the basic design of IO processing in VMS.
  47.  
  48.         Merry VAXmas,
  49.  
  50.                 Nigel Arnot
  51.  
  52.                 NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
  53.                 NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
  54.