🚀 go-pugleaf

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.