🚀 go-pugleaf

In article <1993Jan26.125545.1@ssrl01.slac.stanford.edu>, tcox@ssrl01.slac.stanford.edu (Tony Cox - (415)926-3105) writes:
|>
|>Does anyone have any experience with user-written drivers on the Alpha?
|>
|>I am hearing conflicting information on the availability of documentation
|>for user written drivers, and hope that someone in this news group can clarify
|>the situation.
|>
|>A specific concern for me is porting my home grown pseudodriver. On VAX/VMS,
|>this driver processes a series of QIO's from application programs,
|>originally written to control a CAMAC serial highway driver. For compatibility
|>with existing systems, these applications cannot be rewritten. The QIO's
|>come down from the application specifying (in p1-p6) three buffers in 
|>user space. The driver locks these pages in memory, using the usual
|>exe$write/read/modify routines, and then passes the request off to a
|>user-written ACP using EXE$QIOACPPKT.
|>The ACP interprets the information (in this case, generating network requests
|>to uVAXIII systems running VAX/ELN), returns information and status into the
|>buffers in the requesting user process, and then completes the request
|>using COM$POST.
|>
|>So this driver/ACP combination is relatively simple (no hardware access, except
|>via supported network drivers), but it _does_ do some things which I would have
|>thought would require some (possibly extensive) code changes when running on
|>the Alpha.
|>
|>For example, the ACP uses system page table entries to map the original
|>user request.
|>
|>Anyone done such a thing, or know about available documentation?
|>
|>Thanks
|>
|>Tony Cox, Stanford,CA
|>TCOX@SSRL01.SLAC.STANFORD.EDU(INet)	SSRL01::TCOX (HEPNet)
|>TCOX@SSRL750 (BitNet)
|>

Tony,
	From what I understand at the beginning DEC's official position 
was "no user written device drivers in V1.0"... however, recently I have seen 
courses that are being taught by DEC on this subject... so I 
guess they have backed off from that position. Realistically, it is not 
very hard to port a pseudo driver to AXP, I have ported a number of 
them in the last year... If this issue is really important to your operation
I would push on the local porting center for more concrete information, you
know it must be available since DEC ported a number of drivers themselves...

-Larry.

In article <1993Jan26.125545.1@ssrl01.slac.stanford.edu>, tcox@ssrl01.slac.stanford.edu (Tony Cox - (415)926-3105) writes:
|>A specific concern for me is porting my home grown pseudodriver. On VAX/VMS,
|>this driver processes a series of QIO's from application programs,
|>originally written to control a CAMAC serial highway driver. For compatibility
|>with existing systems, these applications cannot be rewritten. The QIO's
|>come down from the application specifying (in p1-p6) three buffers in 
|>user space. The driver locks these pages in memory, using the usual
|>exe$write/read/modify routines, and then passes the request off to a
|>user-written ACP using EXE$QIOACPPKT.
|>The ACP interprets the information (in this case, generating network requests
|>to uVAXIII systems running VAX/ELN), returns information and status into the
|>buffers in the requesting user process, and then completes the request
|>using COM$POST.
|>
|>So this driver/ACP combination is relatively simple (no hardware access, except
|>via supported network drivers), but it _does_ do some things which I would have
|>thought would require some (possibly extensive) code changes when running on
|>the Alpha.

If you're familiar with designing and implementing this on VAX/VMS, you
shouldn't have too much difficulty porting it to AXP/VMS. At least for
the Stage 1 drivers, the code is quite similar, with mainly such things as
structure member size promotions and physical page size issues to deal with.
I ported a pseudo-driver and ACP combination which sounds pretty similar
to yours a few months ago, and didn't have too much trouble with it.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.