On 2023-09-18, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Mon, 2023-09-18 at 17:04 +0200, Johnny Billquist wrote:
>> > It should be straightforward to port the existing X11 driver for
>> > Virtualbox or VMware to OpenVMS. The x86 driver already exists for
>> > Linux.
>>
>> Uh? How did you come to the conclusion that some driver from Linux
>> would be straight forward to port to VMS? There aren't exactly much
>> commonality between the internals in Linux and VMS...
>
> The driver model in VMS may be very different to what is expected in
> Linux but the basics of controlling the device itself does't change.
> Likewise for X11.
>

Understanding how a device works is only one part of writing a successful
device driver, especially on VMS.

I wrote a VMS device driver once for VMS about 20 years ago just for fun,
and it was such a painful exercise compared to writing a device driver
for Linux, that I _never_ did it again. :-)

[It was back in the days of analogue TV, and I put a WinTV PCI card into
an AlphaStation and wrote a device driver to pull the teletext data stream
out of the video signal and display teletext pages on a VT emulator.
Like I said above, this was just for fun.]

For one thing, unlike Linux, there is absolutely _no_ kernel module
support in VMS. On VMS, when you need to reload your device driver
while trying to get things to work, you need to reboot your system
_every_ _single_ _time_ you want to load an updated device driver. :-( :-(

Also, unless things have changed in recent years, the only example
device driver provided is LRDRIVER, which doesn't even begin to address
a wide range of more advanced topics. On Linux, if you want to understand
some complex or subtle device driver concept, you can just pick a device
driver that uses this concept and study how that device driver did it.

Oh, and don't even _think_ about trying to write your own filesystem
driver for VMS unless you are willing to purchase the VMS source code kit,
as there's absolutely no public documentation on that.

On Linux however, the VFS infrastructure is beautifully elegant:

https://docs.kernel.org/filesystems/vfs.html

Wish you could do _that_ on VMS.

> Hopefully VSI has documentation on implementing drivers in x86_64 on
> their website, I would definitely take a look.

I doubt it.

When sanity prevailed, and DEC allowed you to write VMS device drivers
in C, it became its own book that you had to purchase. That was for Alpha,
and I never saw anything for Itanium, and IIRC, it's been mentioned that
there will not be a device driver book for x86-64 as well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Tuesday, September 19, 2023 at 1:40:17 PM UTC-4, Simon Clubley wrote:
> For one thing, unlike Linux, there is absolutely _no_ kernel module
> support in VMS. On VMS, when you need to reload your device driver
> while trying to get things to work, you need to reboot your system
> _every_ _single_ _time_ you want to load an updated device driver. :-( :-(

The early versions of VAX/VMS let you reload drivers, it was quite convenient.

I never tried to write a device driver from scratch, but I have tweaked a couple.

On Tue, 19 Sep 2023 13:37:48 -0700, David Jones wrote:

> On Tuesday, September 19, 2023 at 1:40:17 PM UTC-4, Simon Clubley wrote:
>> For one thing, unlike Linux, there is absolutely _no_ kernel module
>> support in VMS. On VMS, when you need to reload your device driver
>> while trying to get things to work, you need to reboot your system
>> _every_ _single_ _time_ you want to load an updated device driver. :-(
>> :-(
>
> The early versions of VAX/VMS let you reload drivers, it was quite
> convenient.

It very much depended on the driver, as I recall.

> I never tried to write a device driver from scratch, but I have tweaked
> a couple.

I wrote two or three, one being a terminal driver that used a cloned
interface and used our weird network. Another did file transfer and stuff.

What helped me a lot was going on the device driver course!

On Tue, 2023-09-19 at 17:40 +0000, Simon Clubley wrote:
> On 2023-09-18, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>
>
> Understanding how a device works is only one part of writing a
> successful device driver, especially on VMS.
>
> I wrote a VMS device driver once for VMS about 20 years ago just for
> fun, and it was such a painful exercise compared to writing a device
> driver for Linux, that I _never_ did it again. :-)
>
> [It was back in the days of analogue TV, and I put a WinTV PCI card
> into an AlphaStation and wrote a device driver to pull the teletext
> data stream out of the video signal and display teletext pages on a
> VT emulator. Like I said above, this was just for fun.]
>
> For one thing, unlike Linux, there is absolutely _no_ kernel module
> support in VMS. On VMS, when you need to reload your device driver
> while trying to get things to work, you need to reboot your system
> _every_ _single_ _time_ you want to load an updated device driver. :-
> ( :-(
>
> Also, unless things have changed in recent years, the only example
> device driver provided is LRDRIVER, which doesn't even begin to
> address a wide range of more advanced topics. On Linux, if you want
> to understand some complex or subtle device driver concept, you can
> just pick a device driver that uses this concept and study how that
> device driver did it.
>
> Oh, and don't even _think_ about trying to write your own filesystem
> driver for VMS unless you are willing to purchase the VMS source code
> kit, as there's absolutely no public documentation on that.
>
> On Linux however, the VFS infrastructure is beautifully elegant:
>
> https://docs.kernel.org/filesystems/vfs.html
>
> Wish you could do _that_ on VMS.
>
> > Hopefully VSI has documentation on implementing drivers in x86_64
> > on their website, I would definitely take a look.
>
> I doubt it.
>
> When sanity prevailed, and DEC allowed you to write VMS device
> drivers in C, it became its own book that you had to purchase. That
> was for Alpha, and I never saw anything for Itanium, and IIRC, it's
> been mentioned that there will not be a device driver book for x86-64
> as well.

Thanks for that, that's good to know. Who knows, I might enjoy the
challenge. And anyway, it is much _easier_ nowadays running these
things inside a VM, for development.
--
Tactical Nuclear Kittens

On 2023-09-19 19:40, Simon Clubley wrote:
> For one thing, unlike Linux, there is absolutely _no_ kernel module
> support in VMS. On VMS, when you need to reload your device driver
> while trying to get things to work, you need to reboot your system
> _every_ _single_ _time_ you want to load an updated device driver. :-( :-(

Sometimes evolution goes backwards. Writing a device driver for RSX is
well documented, and fairly straight forward. And there are no problems
unloading and loading device drivers on a running system.

That said - it's still not something for people who don't understand a
lot of low level and kernel internal stuff.

Johnny

On Tuesday, September 19, 2023 at 10:40:17 AM UTC-7, Simon Clubley wrote:
>
> I wrote a VMS device driver once for VMS about 20 years ago just for fun,
> and it was such a painful exercise compared to writing a device driver
> for Linux, that I _never_ did it again. :-)
>
> (snip)
>
> Also, unless things have changed in recent years, the only example
> device driver provided is LRDRIVER, which doesn't even begin to address
> a wide range of more advanced topics. On Linux, if you want to understand
> some complex or subtle device driver concept, you can just pick a device
> driver that uses this concept and study how that device driver did it.

As luck would have it, during a burst of hacking on OpenVMS and specifically GNV last year, I found a different device driver example, LAVDRIVER, which computes the system load average so that GNU coreutils programs that call getloadavg() will get useful info to print.

https://github.com/jhamby/vms-laxdriver

I didn't like that it was written in MACRO, and also I realized that I'd need to modify the calling interface to return IEEE FP values instead of VAX FP since that was what I was compiling GNU coreutils with. So I renamed it to LAXDRIVER (LAX0:) and ported the code to C, using LRDRIVER as an example of the C interface. The original LAVDRIVER was on a VMS Freeware CD, and MultiNet happened to install a binary of it. I found a link to my original post announcing my version, in which I was quite excited.

https://groups.google.com/g/comp.os.vms/c/02fLMYKM0TE/m/4iXSMQaHBAAJ

I'm very interested to revisit this code on OpenVMS x86 to see whether it builds and runs, and if it has the same issue with returning a higher load average than it should, like I saw on a dual-CPU Itanium.

Cheers,
Jake

On Tuesday, October 10, 2023 at 7:59:59 PM UTC-7, Jake Hamby (Solid State Jake) wrote:

> I didn't like that it was written in MACRO, and also I realized that I'd need to modify the calling interface to return IEEE FP values instead of VAX FP

Correction: I changed my C version of the driver to return 32-bit fixed-point values, not IEEE FP. It's normally not allowed to use the FPU in a device driver running in kernel mode, but I assume that it must have been allowed, since the original LAVDRIVER appears to work on Alpha and Itanium. I believe at least Linux and the BSDs implement the system call as returning fixed-point values and then the libc wrapper converts them to an array of three doubles.

I say the FPU "appears to work" in VMS device drivers because I have no idea if it's reliable or if it only happens to work in this case due to nobody else using the FPU while I was running tests. The reason the FPU is almost never allowed in kernel mode, at least in UNIX derivatives, is that it adds a large additional register bank (esp. with SSE and other SIMD extensions) that has to be saved/restored on thread context switches.

BTW, the GNV coreutils client code to read from the original LAVDRIVER is buggy because there's a mismatch of expectations between "float" and "double". It's interesting that nobody has really inspected some of this 1990s-era VMS code enough to notice when it isn't actually working.

Cheers,
Jake