home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / alpha / 154 < prev    next >
Encoding:
Text File  |  1993-01-27  |  2.8 KB  |  65 lines
  1. Newsgroups: vmsnet.alpha
  2. Path: sparky!uunet!eco.twg.com!eco.twg.com!larry
  3. From: larry@eco.twg.com (Lawrence B. Henry III)
  4. Subject: Re: User-written device drivers on Alpha/VMS
  5. Message-ID: <1993Jan27.173713.3675@eco.twg.com>
  6. Lines: 50
  7. Sender: larry@vishnu.eco.twg.com (Lawrence B. Henry III)
  8. Nntp-Posting-Host: eco.twg.com
  9. Reply-To: larry@eco.twg.com
  10. Organization: The Wollongong Group (East Coast Operations)
  11. References:  <1993Jan26.125545.1@ssrl01.slac.stanford.edu>
  12. Date: Wed, 27 Jan 93 17:37:13 GMT
  13. Lines: 50
  14.  
  15.  
  16. In article <1993Jan26.125545.1@ssrl01.slac.stanford.edu>, tcox@ssrl01.slac.stanford.edu (Tony Cox - (415)926-3105) writes:
  17. |>
  18. |>Does anyone have any experience with user-written drivers on the Alpha?
  19. |>
  20. |>I am hearing conflicting information on the availability of documentation
  21. |>for user written drivers, and hope that someone in this news group can clarify
  22. |>the situation.
  23. |>
  24. |>A specific concern for me is porting my home grown pseudodriver. On VAX/VMS,
  25. |>this driver processes a series of QIO's from application programs,
  26. |>originally written to control a CAMAC serial highway driver. For compatibility
  27. |>with existing systems, these applications cannot be rewritten. The QIO's
  28. |>come down from the application specifying (in p1-p6) three buffers in 
  29. |>user space. The driver locks these pages in memory, using the usual
  30. |>exe$write/read/modify routines, and then passes the request off to a
  31. |>user-written ACP using EXE$QIOACPPKT.
  32. |>The ACP interprets the information (in this case, generating network requests
  33. |>to uVAXIII systems running VAX/ELN), returns information and status into the
  34. |>buffers in the requesting user process, and then completes the request
  35. |>using COM$POST.
  36. |>
  37. |>So this driver/ACP combination is relatively simple (no hardware access, except
  38. |>via supported network drivers), but it _does_ do some things which I would have
  39. |>thought would require some (possibly extensive) code changes when running on
  40. |>the Alpha.
  41. |>
  42. |>For example, the ACP uses system page table entries to map the original
  43. |>user request.
  44. |>
  45. |>Anyone done such a thing, or know about available documentation?
  46. |>
  47. |>Thanks
  48. |>
  49. |>Tony Cox, Stanford,CA
  50. |>TCOX@SSRL01.SLAC.STANFORD.EDU(INet)    SSRL01::TCOX (HEPNet)
  51. |>TCOX@SSRL750 (BitNet)
  52. |>
  53.  
  54. Tony,
  55.     From what I understand at the beginning DEC's official position 
  56. was "no user written device drivers in V1.0"... however, recently I have seen 
  57. courses that are being taught by DEC on this subject... so I 
  58. guess they have backed off from that position. Realistically, it is not 
  59. very hard to port a pseudo driver to AXP, I have ported a number of 
  60. them in the last year... If this issue is really important to your operation
  61. I would push on the local porting center for more concrete information, you
  62. know it must be available since DEC ported a number of drivers themselves...
  63.  
  64. -Larry.
  65.