[Info-vax] VMS device drivers

[John Reagan]

On 1/12/2024 9:20 AM, Simon Clubley wrote:
> On 2024-01-12, Single Stage to Orbit <alex.buell at munted.eu> wrote:
>> On Fri, 2024-01-12 at 01:46 +0000, Gary Sparkes wrote:
>>> I'm highly waiting on this, while testing some devices and code in
>>> Alpha and Itanium systems, for when that floodgate opens. A fair
>>> amount of things i'm working on are hardware support for specialty
>>> things, and lack of being able to (so far) load my own drivers
>>> without some insane steps is... well, putting things on hold for
>>> people who're excited to get rid of some older hardware.
>>
>> I've been told writing drivers for OpemVMS/x86 is an insane process!
> 
> Even more so than writing one for Alpha ?
> 
> If so, how did they manage to make the process even more insane ?
> 
> Simon.
> 

While I'm not a device driver expert, x86 device drivers should function
much like their prior counterparts.  There are a few areas that changed.

Interesting fields in the PTEs (page table entries) moved from the
bottom 32-bits to the upper 32-bits (x86 architecture defined these)
so Macro-32 written drivers had to inspect the various instructions
and change to EVAX_ 64-bit instructions.  I believe that macros were
written to hide those details but some drivers might have been rewritten
into C in the process.  [I'm a big fan of eliminating Macro-32 code.
I have a long-standing joke of paying $5 per module for any rewrite out
of Macro-32 into ANY other language.]

The other area was with a concept SVAPTE (System Virtual Address PTE)
where a piece of 64-bit memory was double-mapped to also be accessible
using 32-bit system addresses.  Such a concept didn't fit with how the
x86 memory management was going to work so all the SVAPTE references
where modified/buried in a macro along with expansion of some of those
32-bit fields into 64-bit fields.  [Don't quote me on the exact details
of these changes.]

However, there were no large conceptual changes to the device driver
architecture for x86.