[Info-vax] VMS device drivers, was: Re: The best VMS features, was: Re: openvms renaming file

[Stephen Hoffman]

On 2018-05-31 12:20:40 +0000, Simon Clubley said:

> On 2018-05-31, Bill Gunshannon <bill.gunshannon at gmail.com> wrote:
>> 
>> My point was that there is little difference between desktop and server 
>> systems today and writing either off is a bad decision.  Can it really 
>> be that hard  to write a device driver for a limited set of graphics 
>> cards?

The completion of the x86-64 port is the overwhelming development 
priority for VSI folks.

VSI doesn't have enough staff for what they need to do and are working 
on.   VSI does not have infinite staff, nor infinite schedule, nor 
infinite focus.

VSI have specifically stated server configurations are the target for 
VSI OpenVMS.   Not desktops.  Definitely not workstations.

VSI folks have discussed supporting the embedded graphics and the 
management graphics.  Intel HD, UHD, Iris, Iris Pro, et al.

VSI does not have an installed base that's using OpenVMS on the 
desktop, beyond some few existing X-based control interfaces and 
related apps.

As for writing drivers?  Sure.  It's a SMOP.   Particularly for an 
isolated one-off device driver.  Graphics drivers are not isolated.   
When last I looked, I'd figured at least a half year and quite possibly 
most of a year of work for an experienced OpenVMS developer already 
familiar with writing and debugging drivers, for design and development 
and testing and integration and documenting of a wholly new graphics 
controller, and that assuming full source access to OpenVMS and 
DECwindows.  One of the few folks that wrote various of the graphics 
drivers died a few years ago, too.  The numbers of folks that have 
written and integrated drivers into DECwindows is considerably smaller 
than the small number of folks that have written OpenVMS device drivers.

That's a ~year away from modifying existing and writing new drivers 
more directly necessary for the OpenVMS x86-64 port, too.

Outside of the processor-embedded graphics hardware, graphics cards 
were coming and going more quickly than that.  Outside of the embedded 
graphics controllers and products from one or two of the graphics 
vendors, most of the graphics controllers were also quite proprietary 
and the vendors were less than willing to provide documentation to 
random folks.   Desktop systems and their configurations and components 
are getting revised and replaced once or twice a year too, and 
variously changed between new products.  There's a whole lot of churn 
in computing.  And more than a little churn among the graphics 
controller products.  "Average shelf life of a fruit fly" and all.  
Which means purchasing and storing whacking great piles of specific 
graphics controllers for resale and with the stocking costs and risks 
that that entails, or playing perpetual catch-up with controllers, or 
variously both.

Then there's that the entire graphics implementation on OpenVMS is 
awful.   From the refresh and resolution controls up through the 
available APIs and to the lack of apps and tools for development of 
graphical applications.

For GUI development tools, Xcode is staggeringly better than anything 
available on OpenVMS, for instance.  I'd have to expect that some of 
the other leading IDEs are in that same range.

And as for client interfaces, we're just starting to see what's 
possible with browser-based clients using WebAssembly, and we already 
know what's possible with JavaScript: https://bellard.org/jslinux/

Then there's that we can't prize many of the OpenVMS developer folks 
away from their character cell interfaces and terminals and LK 
keyboards, and those that do look around are moving to web clients for 
the apps, or dedicated app clients running on the client platforms.  To 
client-server user interfaces, as it that was once commonly known.

> It's harder on VMS than it is on Linux.
> 
> You can't reload device drivers on VMS so you need to reboot your test 
> system every single time you change something and want to load a new 
> version of the driver.
> 
> Also, what functionality is required ? Is a framebuffer driver 
> sufficient or would you need a driver with acceleration support ?
> 
> It's also a pity VMS doesn't have user mode device drivers.
> 
> Yes, VMS has ACPs which can be used in some situations but how to write 
> one is totally undocumented.

Drivers are but one part of the work involved.  Reboots aren't nearly 
as tedious as they once were either, and particularly if the box is 
configured to skip most or all of POST.

Yeah; ACPs aren't too bad and that having written several, though there 
were a few bugs in the one bit of third-party ACP documentation that 
was available within a long out-of-print third-party book; Leahy and 
Hanrahan's VMS Advanced Device Driver Techniques.  There's a whole lot 
of missing code around mounts and dismounts that the developer has to 
write.  And remote debugging is somewhere between helpful and 
necessary, either via app-embedded DECterm usage or via embedded 
debugging.

An ACP doesn't get you a good path into the graphics controller and GPU 
from user mode through the system.  Frame buffer or otherwise.  There 
are security concerns around the increasing capabilities and access of 
GPUs. too.   The connect-to-interrupt stuff disappeared long ago.

Beyond the device drivers and X integration, most folks with current or 
new apps are gong to want CUDA or OpenCL or OpenGL or ilk, and GTK+ or 
Qt or ilk, for application access.  X of the vintage that's offered on 
OpenVMS isn't going to be popular.

There are hardware differences between servers and workstations.  
Servers and workstations usually have a different mixture of PCIe 
slots.  And different mixtures of external I/O connections, for that 
matter.  Servers tend to focus on remote management and hardware 
whichever niche the server is focused on, while workstations tend to 
focus on x16 slots — which are not useful on OpenVMS — and fewer or no 
x4 slots.  Low- to mid-range desktops have embedded graphics, while 
that's not so common in workstations.  Servers and some higher-end 
workstations tend to have Xeon or ilk, and EDC/ECC features.

Hardware differences between desktops and servers aside, X support on 
OpenVMS is old and problematic, and there are comparatively few (no?) 
current X apps for OpenVMS.  No current X toolkits and development 
tools and frameworks, either.   BX was the third-party replacement for 
VUIT, and that's all long gone on OpenVMS.  Then there's what you're 
going to do with the configuration.   There are few desktop apps for 
OpenVMS.  What's been around for OpenVMS has been embedded and 
purpose-built X apps with some running locally and some running 
remotely, and those haven't changed substantially in decades.  And 
changes to those apps are headed toward remote displays from 
purpose-built clients or browser-based user interfaces.  Not enough 
folks to matter are going to be interested in spreadsheets or WYSIWYG 
document preparation on OpenVMS, much less the browsers and multimedia 
support that's commonplace on desktop-targeted and mobile-targeted 
configurations.  And all the "fun" that is DRM and HDCP, just as soon 
as those enter scope.

DEC and OpenVMS ceded the desktop circa 1995.  The trends were clear then, too.

Maybe when the x86-64 port is available and stable and OpenVMS servers 
are increasing in sales, then maybe VSI can review and retarget and 
staff and expand, and can work to slim down and clean up and tailor an 
OpenVMS distribution and its power management and APIs and other 
details expected for and increasingly provided for desktop use.  But 
pragmatically the chances of OpenVMS replacing Windows or AOSP or iOS 
is somewhere around zilch.  Linux is in a much, much better situation, 
and the comments about "The Year of Linux on the Desktop" still 
circulate.  Whatever local management processor and/or embedded 
processor and remote X and DECwindows is where we are and what we have, 
for the foreseeable future.

So... sure... writing a device driver is a SMOP.  Given the hardware 
doc and/or the time to reverse the hardware.  Given the time to 
retrofit the driver into X and DECwindows on OpenVMS.  To preferably 
also document how that has to happen, too.   Lots of SMOPs in this 
business.  Figuring out which SMOPs are feasible and then which of 
those are going to be profitable is the detail that matters.   OpenVMS 
on a desktop?  Beyond what X provides for the existing OpenVMS apps 
locally and/or remotely, that's going to be a very tough sale.



-- 
Pure Personal Opinion | HoffmanLabs LLC