I'm not quite ready to announce a V1.0 release, but I'm pleased to share my first VMS device driver, not for a physical hardware device, but a replacement for the old LAVDRIVER load average driver written in MACRO. With the recent thread bemoaning the lack of good examples of how to write a device driver in C, I'm happy to add to the collection of open source examples.

I'm in the process of upgrading the GNV packages with various bug fixes, although my branch is definitely not as stable as the release packages. However, there's a bug in coreutils in "uptime", "w", and other programs that show the load average.

The getloadavg.c code in the original coreutils source actually has VMS support (and Eunice too, if you can believe that), but it's buggy: it thinks the values it's reading are doubles and not floats. But there's an even bigger issue: GNU coreutils is compiled with IEEE floating point (as it should be), while the LAVDRIVER returns VAX 32-bit floats.

Long story short, I realized that the LAVDRIVER.EXE that MultiNet provides was likely going to be inefficient if it's still written in VAX assembly, and I can hardly believe they would be using floating-point at all in the kernel. The more I looked at the problem, I realized it wouldn't be advisable, and perhaps not even safe at all, to touch the FP registers. Much better to use and return fixed-point integers, so that's what I did. I rewrote my own LAXDRIVER in C and it seems to work fairly well, at least on Alpha and Itanium (after many crashes and false starts on the Alpha, which is easy to get crash info from).

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

I've put it under an MIT license: it's all my original work, except for the skeleton and some of the function comments that came from the sample LRDRIVER.C in sys$examples that I used as a template (I'm sure VSI won't mind since they put the code there as an example). There's a test app you can compile as test-lav-driver.exe to read from the original VAX FP LAVDRIVER, or with /float=ieee to build as test-lax-driver.exe and read fixed-point with 14-bit scaling factor from my new driver.

I do have one apparent bug in the load average that I'm calculating, and without access to any internals docs newer than for V7.0, perhaps some changes have been made to the scheduler that I don't understand, so I'd be grateful for any insight into what's happening:

When I have 2 process each using 100% CPU on a two-CPU Itanium, the load average settles in at around 3.5 to 4.0, or rather fluctuates between those two. It should be much closer to 2.0, with two runnable processes and two cores (it's a bug in the original LAVDRIVER to divide the load average by the number of CPUs; no other OS I know of does that).

Relatedly, in MONITOR, I can also see 2 CUR and 2 COM at the same time. I don't understand how I could be seeing processes marked as CURrent in the per-CPU table and yet also counting the same process as COMputable. Is that a bug or do I need to do something more than hold the SCHED lock?

Regards,
Jake Hamby

On 2022-06-17, Jake Hamby <jake.hamby@gmail.com> wrote:
> I'm not quite ready to announce a V1.0 release, but I'm pleased to share my first VMS device driver, not for a physical hardware device, but a replacement for the old LAVDRIVER load average driver written in MACRO. With the recent thread bemoaning the lack of good examples of how to write a device driver in C, I'm happy to add to the collection of open source examples.
>
> I'm in the process of upgrading the GNV packages with various bug fixes, although my branch is definitely not as stable as the release packages. However, there's a bug in coreutils in "uptime", "w", and other programs that show the load average.
>
> The getloadavg.c code in the original coreutils source actually has VMS support (and Eunice too, if you can believe that), but it's buggy: it thinks the values it's reading are doubles and not floats. But there's an even bigger issue: GNU coreutils is compiled with IEEE floating point (as it should be), while the LAVDRIVER returns VAX 32-bit floats.
>
> Long story short, I realized that the LAVDRIVER.EXE that MultiNet provides was likely going to be inefficient if it's still written in VAX assembly, and I can hardly believe they would be using floating-point at all in the kernel. The more I looked at the problem, I realized it wouldn't be advisable, and perhaps not even safe at all, to touch the FP registers. Much better to use and return fixed-point integers, so that's what I did. I rewrote my own LAXDRIVER in C and it seems to work fairly well, at least on Alpha and Itanium (after many crashes and false starts on the Alpha, which is easy to get crash info from).
>
> https://github.com/jhamby/vms-laxdriver
>

First off, thanks for posting this.

> I've put it under an MIT license: it's all my original work, except for the skeleton and some of the function comments that came from the sample LRDRIVER.C in sys$examples that I used as a template (I'm sure VSI won't mind since they put the code there as an example). There's a test app you can compile as test-lav-driver.exe to read from the original VAX FP LAVDRIVER, or with /float=ieee to build as test-lax-driver.exe and read fixed-point with 14-bit scaling factor from my new driver.
>

It may not be that simple. VSI are constrained by what the HPE contract says
and the copyrights on the original source code.

For example, just because the EVE source code is in sys$examples, it doesn't
mean that VSI or a VMS user can just post it on GitHub (for example).

That said, I do hope that you are right.

> I do have one apparent bug in the load average that I'm calculating, and
> without access to any internals docs newer than for V7.0, perhaps some
> changes have been made to the scheduler that I don't understand, so I'd be
> grateful for any insight into what's happening:
>

Have you considered asking Brian to look at your code ? He might have some
insights for you.

$ set response/mode=good_natured

Of course, if Brian says to rewrite it in Macro-32, then feel free to ignore
him. :-)

Simon.

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

On 6/20/2022 8:59 AM, Simon Clubley wrote:
> On 2022-06-17, Jake Hamby <jake.hamby@gmail.com> wrote:
>> I've put it under an MIT license: it's all my original work, except
>> for the skeleton and some of the function comments that came from
>> the sample LRDRIVER.C in sys$examples that I used as a template
>> (I'm sure VSI won't mind since they put the code there as an
>> example). There's a test app you can compile as test-lav-driver.exe
>> to read from the original VAX FP LAVDRIVER, or with /float=ieee to
>> build as test-lax-driver.exe and read fixed-point with 14-bit
>> scaling factor from my new driver. >
> It may not be that simple. VSI are constrained by what the HPE contract says
> and the copyrights on the original source code.
>
> For example, just because the EVE source code is in sys$examples, it doesn't
> mean that VSI or a VMS user can just post it on GitHub (for example).
>
> That said, I do hope that you are right.

Copyright rules are pretty strict. Stuff in SYS$EXAMPLES
are copyrighted and one need permission to use
copyrighted material.

But I think in this case one could try argue:
- the stuff in SYS$EXAMPLES are obviously intended
to be used so it must be OK to use it at
least locally
- everybody using this code will obviously have
a VMS system and a SYS$EXAMPLES with the same
stuff already, so it is distributing code to people
that already have a legal copy of that code

The argument also points to a workaround: distribute
only ones own code and a script that merge it with
SYS$EXAMPLES stuff.

Arne

On Monday, June 20, 2022 at 11:20:15 AM UTC-7, Arne Vajhøj wrote:
> > That said, I do hope that you are right.
> Copyright rules are pretty strict. Stuff in SYS$EXAMPLES
> are copyrighted and one need permission to use
> copyrighted material.
>
> But I think in this case one could try argue:
> - the stuff in SYS$EXAMPLES are obviously intended
> to be used so it must be OK to use it at
> least locally
> - everybody using this code will obviously have
> a VMS system and a SYS$EXAMPLES with the same
> stuff already, so it is distributing code to people
> that already have a legal copy of that code
>
> The argument also points to a workaround: distribute
> only ones own code and a script that merge it with
> SYS$EXAMPLES stuff.

At some point I'll replace the comments with something shorter and written in my own style. I didn't want to do that originally mostly because I didn't want to claim authoritatively the system states that are described in the comments for the different callback functions that I filled in with my own code.

I'm still curious what's accounting for the load average being higher than I'd expect when there are 2 running/computable processes and 2 CPUs. I'd expect to see values closer to 2.0 than 3.5 to 4.0. At least it shows ~0.01 when idle. It looks to all appearances like a running process can show up as computable and also current on a CPU, including in the MONITOR system process counts. Not that this is the sort of thing that a hardware device driver would ever be concerned with, as opposed to a pseudo-device driver that's poking around in the system state.

Jake Hamby wrote:
> On Monday, June 20, 2022 at 11:20:15 AM UTC-7, Arne Vajhøj wrote:
>>> That said, I do hope that you are right.
>> Copyright rules are pretty strict. Stuff in SYS$EXAMPLES
>> are copyrighted and one need permission to use
>> copyrighted material.
>>
>> But I think in this case one could try argue:
>> - the stuff in SYS$EXAMPLES are obviously intended
>> to be used so it must be OK to use it at
>> least locally
>> - everybody using this code will obviously have
>> a VMS system and a SYS$EXAMPLES with the same
>> stuff already, so it is distributing code to people
>> that already have a legal copy of that code
>>
>> The argument also points to a workaround: distribute
>> only ones own code and a script that merge it with
>> SYS$EXAMPLES stuff.
>
> At some point I'll replace the comments with something shorter and written in my own style. I didn't want to do that originally mostly because I didn't want to claim authoritatively the system states that are described in the comments for the different callback functions that I filled in with my own code.
>
> I'm still curious what's accounting for the load average being higher than I'd expect when there are 2 running/computable processes and 2 CPUs. I'd expect to see values closer to 2.0 than 3.5 to 4.0. At least it shows ~0.01 when idle. It looks to all appearances like a running process can show up as computable and also current on a CPU, including in the MONITOR system process counts. Not that this is the sort of thing that a hardware device driver would ever be concerned with, as opposed to a pseudo-device driver that's poking around in the system state.

I don't have the internals manual here just now, and things may have
changed in later versions of VMS anyways, but when a process is made
CUR, is it actually removed from the COM queue?

Also, depending on how you are scanning the queues, processes can move
between queues while you are scanning.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: chris@applied-synergy.com
Fax: 817-237-3074