Listening to the latest webinar, it was mentioned that a common question
from customers was about support of specific hardware. At that point, I
realised that the variety of x86 server hardware currently available
probably exceeds the total variety of all the hardware that VMS has ever
run on.

Yes. All the variations of VAX, Alpha and Itanium that have ever been
supported likely provided less variety - in terms of devices to support -
than the variety of x86 server hardware that's _currently_ available,
ignoring all the x86 kit that is no longer on sale, but still viable.

How the hell is this managed for Windows and Linux? For those OSes, the
manufacturers do a lot of the work of writing and testing device drivers.
Microsoft have to do a lot themselves for Windows, and also provide SDKs
and templates. For Linux, the big distributors, such as Red Hat, do quite
a bit. There are also consultancies that write drivers for manufacturers,
and/or provide training and SDKs.

For VMS, at present, there's just VSI. They aren't a big company and they
have a lot of work to do without doing lots of drivers. An obvious
solution would be to switch to a hypervisor-only support model, but it
appears that many customers want to work on bare metal.

I can't find any information on the VSI website about writing device
drivers. There might be an opening for a company who produced device
drivers for customers.

John

Den 2022-05-12 kl. 21:07, skrev John Dallman:
> Listening to the latest webinar, it was mentioned that a common question
> from customers was about support of specific hardware. At that point, I
> realised that the variety of x86 server hardware currently available
> probably exceeds the total variety of all the hardware that VMS has ever
> run on.
>
> Yes. All the variations of VAX, Alpha and Itanium that have ever been
> supported likely provided less variety - in terms of devices to support -
> than the variety of x86 server hardware that's _currently_ available,
> ignoring all the x86 kit that is no longer on sale, but still viable.
>
> How the hell is this managed for Windows and Linux? For those OSes, the
> manufacturers do a lot of the work of writing and testing device drivers.
> Microsoft have to do a lot themselves for Windows, and also provide SDKs
> and templates. For Linux, the big distributors, such as Red Hat, do quite
> a bit. There are also consultancies that write drivers for manufacturers,
> and/or provide training and SDKs.
>
> For VMS, at present, there's just VSI. They aren't a big company and they
> have a lot of work to do without doing lots of drivers. An obvious
> solution would be to switch to a hypervisor-only support model, but it
> appears that many customers want to work on bare metal.

I thought that VSI said that the increast focus on VM environments is
due to customer demands. As I understand, the major part of VSI income
comes from customers where running in a VM is the prefered solution.

>
> I can't find any information on the VSI website about writing device
> drivers. There might be an opening for a company who produced device
> drivers for customers.

I really can't see the need today. Just run in a VM and you have all
the driver support you'll evr need. Special hardware that you might
need to communicate with, is probably network/TCPIP connected anyway.

So, I see no business case for custom written device drivers today.

Jan-Erik.

>
> John

On 2022-05-12 19:08:00 +0000, John Dallman said:

> Listening to the latest webinar, it was mentioned that a common
> question from customers was about support of specific hardware. At that
> point, I realised that the variety of x86 server hardware currently
> available probably exceeds the total variety of all the hardware that
> VMS has ever run on.
>
> Yes. All the variations of VAX, Alpha and Itanium that have ever been
> supported likely provided less variety - in terms of devices to support
> - than the variety of x86 server hardware that's _currently_ available,
> ignoring all the x86 kit that is no longer on sale, but still viable.
>
> How the hell is this managed for Windows and Linux? For those OSes, the
> manufacturers do a lot of the work of writing and testing device
> drivers. Microsoft have to do a lot themselves for Windows, and also
> provide SDKs and templates. For Linux, the big distributors, such as
> Red Hat, do quite a bit. There are also consultancies that write
> drivers for manufacturers, and/or provide training and SDKs.
>
> For VMS, at present, there's just VSI. They aren't a big company and
> they have a lot of work to do without doing lots of drivers. An obvious
> solution would be to switch to a hypervisor-only support model, but it
> appears that many customers want to work on bare metal.
>
> I can't find any information on the VSI website about writing device
> drivers. There might be an opening for a company who produced device
> drivers for customers.

Most hardware vendor folks that want to sell hardware will perform the
hardware qualification themselves for Microsoft Windows, and get onto
the Microsoft HCL.

Where this gets more interesting for third-parties are hardware or
firmware bugs that are not exposed by Windows. Some vendors will fix,
some won't.

For VSI, dependencies on hypervisor software devices avoid the
immediate need to write (more) drivers, and virtio support or
equivalent will help here, and use of UEFI means that boot drivers can
potentially be easier to avoid, though all that at the cost of (some)
performance.

How large the performance cost might be is not yet clear.

For cases where performance is a factor, paravirtualization (and
virtio) reduces some of the effort.

There are some OpenVMS device drivers—graphics drivers,
particularly—that require at least source listings and quite possibly
source code access.

The little-known OpenVMS SHIP kits reduced some of the difficulties for
bootstrapping unsupported third-party storage, and the combination of
UEFI and hypervisor support will probably reduce that difficulty for
this upcoming era.

For hardware support configuration information, VSI has not publicized
an equivalent to SPOCK (backronym'd to Single Point Of Connectivity
Knowledge), or Enterprise Configurator, or ilk.

Compaq used Evernote for a while, which worked for what they were doing
with it; mainly storing QuickSpecs-like and
software-product-description-like documents, and not the hardware
detail from SPOCK.

In later parts of those same earlier times, this configuration data
detail all got to be a yet bigger mess when the OpenVMS information was
dropped from HP/HPE SPOCK, too.

Past a trivial and relatively static hardware support configuration
matrix document, the only way this information can be reasonably
maintained and updated and disseminated is with a database and not a
PDF somewhere. Configuration details here include hardware and firmware
revision, and the numbers of devices tested and supported, among other
details.

This qualification list gets even more interesting in some cases, as
hardware vendors can and have updated hardware without updating
revisions. Met that case with one very-well-known vendor's storage
hardware, where one device from the vendor worked and another didn't,
and a teardown found these two same-vendor, same-model, and
same-revision devices were internally very different devices. And the
newer device... failed.

What will happen for folks buying hardware configurations? I suspect
most folks will either use what VSI tests and supports, or what
third-party folks might test and support and package and sell, or—for
somewhat unusual requirements—occasionally third-party drivers. It'll
be fairly unusual for an end-user to create a device driver, absent
plans for a fairly substantial installed base for that end-user. If
you're rolling out a sizable deployment, or selling a supported
hardware configuration, the costs of custom drivers can be absorbed by
the buyer. Or by the seller, for a large enough purchase. And with
UEFI, probably also lacking the boot problems that traditionally arose
with third-party boot storage, absent EFI and SHIP support.

This whole area has all been discussed once or twice before. For some
of those previous discussions, SPOCK will be a pretty good search
target.

ps: If you want to see one example of a semi-related listing from this
era: https://www.synology.com/en-us/compatibility

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, May 12, 2022 at 12:22:48 PM UTC-7, Jan-Erik Söderholm wrote:
> Den 2022-05-12 kl. 21:07, skrev John Dallman:
> >
> > For VMS, at present, there's just VSI. They aren't a big company and they
> > have a lot of work to do without doing lots of drivers. An obvious
> > solution would be to switch to a hypervisor-only support model, but it
> > appears that many customers want to work on bare metal.
> I thought that VSI said that the increast focus on VM environments is
> due to customer demands. As I understand, the major part of VSI income
> comes from customers where running in a VM is the prefered solution.

That's right. One of the drawbacks of Itanium (and Alpha) is that there's only one provider of hypervisors, and no cloud VM providers. The only limitation I can see now with using VMS on supported hypervisors is that they don't yet support AMD CPUs. Once they add support for AMD, there's hyperthreading, which VMS could probably learn to support better, but not many other differences that are even detectable by guests.

> > I can't find any information on the VSI website about writing device
> > drivers. There might be an opening for a company who produced device
> > drivers for customers.
> I really can't see the need today. Just run in a VM and you have all
> the driver support you'll evr need. Special hardware that you might
> need to communicate with, is probably network/TCPIP connected anyway.
>
> So, I see no business case for custom written device drivers today.

Never say never. :) There's the proof-of-concept of using VMS for embedded devices on Intel Atom. It's conceivable that VMS could be a practical realtime OS for industrial applications again. I was recently sent a link to the VAX/VMS Realtime Users Guide from 1980: other than 64-bitness, the advice in there seems reasonable enough to me today, which is a demonstration that VMS could have potential there today on commodity hardware.

http://bitsavers.org/pdf/dec/vax/vms/2.0/AA-H784A-TE_VAX_VMS_2.0_Real-Time_Users_Guide_198003.pdf

Besides realtime process control, no, I don't see much need for custom VMS device drivers, or at least not that customers would pay money for. Ideally, for servers, I would love to see VSI get funding to port to AArch64, or even ppc64le (I know the second one's wishful thinking on my part), and those would also not need any driver support to run in supported cloud VMs.

Jake

Le 12/05/2022 à 21:22, Jan-Erik Söderholm a écrit :
> Den 2022-05-12 kl. 21:07, skrev John Dallman:
>> Listening to the latest webinar, it was mentioned that a common question
>> from customers was about support of specific hardware. At that point, I
>> realised that the variety of x86 server hardware currently available
>> probably exceeds the total variety of all the hardware that VMS has ever
>> run on.
>>
>> Yes. All the variations of VAX, Alpha and Itanium that have ever been
>> supported likely provided less variety - in terms of devices to support -
>> than the variety of x86 server hardware that's _currently_ available,
>> ignoring all the x86 kit that is no longer on sale, but still viable.
>>
>> How the hell is this managed for Windows and Linux? For those OSes, the
>> manufacturers do a lot of the work of writing and testing device drivers.
>> Microsoft have to do a lot themselves for Windows, and also provide SDKs
>> and templates. For Linux, the big distributors, such as Red Hat, do quite
>> a bit. There are also consultancies that write drivers for manufacturers,
>> and/or provide training and SDKs.
>>
>> For VMS, at present, there's just VSI. They aren't a big company and they
>> have a lot of work to do without doing lots of drivers. An obvious
>> solution would be to switch to a hypervisor-only support model, but it
>> appears that many customers want to work on bare metal.
>
> I thought that VSI said that the increast focus on VM environments is
> due to customer demands. As I understand, the major part of VSI income
> comes from customers where running in a VM is the prefered solution.
>
>>
>> I can't find any information on the VSI website about writing device
>> drivers. There might be an opening for a company who produced device
>> drivers for customers.
>
> I really can't see the need today. Just run in a VM and you have all
> the driver support you'll evr need. Special hardware that you might
> need to communicate with, is probably network/TCPIP connected anyway.
>
> So, I see no business case for custom written device drivers today.
Do you live near a nuclear plant? Do you think you would be pleased to
know the OS used to control it has part of it on the cloud?

Do you take underground? What about being somewhere in it and there is
just a subtle problem somewhere in the VmWare?

I don't want to relaunch all the chat around virtual or not virtual. But
it is just: yes there are use cases for bare metal. Minority? yes, not
in the Bid Trend? yes. VSI is right on its choices? I'm not VSI.

I heard on the last webinar VSI saying something like "if you realy need
bare metal, call us and we'll see what can be done on specific
hardwares". Not at all now a priority, but something can be done.
Impossible to be microsoft or large linux community to support any
hardware, but, yes, developping specific drivers could be done.

You know there is a litterature about that for Vax, Alpha (perhaps
itanium, I don't know). It is because it was possible for ISV to develop
drivers for their products. I don't know how many did that. But it is a
normal situation, and it is possible we'll have something like that for
x86. VSI is thinking about a community with its -for-a-far-future-
project Atom. Perhaps there will be another community for the
-not-so-far-project developping some specific drivers for specific bare
metal x86 VMS.

Gérard Calliet
>
> Jan-Erik.
>
>>
>> John
>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Den 2022-05-12 kl. 22:40, skrev Gérard Calliet:
> Le 12/05/2022 à 21:22, Jan-Erik Söderholm a écrit :
>> Den 2022-05-12 kl. 21:07, skrev John Dallman:
>>> Listening to the latest webinar, it was mentioned that a common question
>>> from customers was about support of specific hardware. At that point, I
>>> realised that the variety of x86 server hardware currently available
>>> probably exceeds the total variety of all the hardware that VMS has ever
>>> run on.
>>>
>>> Yes. All the variations of VAX, Alpha and Itanium that have ever been
>>> supported likely provided less variety - in terms of devices to support -
>>> than the variety of x86 server hardware that's _currently_ available,
>>> ignoring all the x86 kit that is no longer on sale, but still viable.
>>>
>>> How the hell is this managed for Windows and Linux? For those OSes, the
>>> manufacturers do a lot of the work of writing and testing device drivers.
>>> Microsoft have to do a lot themselves for Windows, and also provide SDKs
>>> and templates. For Linux, the big distributors, such as Red Hat, do quite
>>> a bit. There are also consultancies that write drivers for manufacturers,
>>> and/or provide training and SDKs.
>>>
>>> For VMS, at present, there's just VSI. They aren't a big company and they
>>> have a lot of work to do without doing lots of drivers. An obvious
>>> solution would be to switch to a hypervisor-only support model, but it
>>> appears that many customers want to work on bare metal.
>>
>> I thought that VSI said that the increast focus on VM environments is
>> due to customer demands. As I understand, the major part of VSI income
>> comes from customers where running in a VM is the prefered solution.
>>
>>>
>>> I can't find any information on the VSI website about writing device
>>> drivers. There might be an opening for a company who produced device
>>> drivers for customers.
>>
>> I really can't see the need today. Just run in a VM and you have all
>> the driver support you'll evr need. Special hardware that you might
>> need to communicate with, is probably network/TCPIP connected anyway.
>>
>> So, I see no business case for custom written device drivers today.
> Do you live near a nuclear plant? Do you think you would be pleased to know
> the OS used to control it has part of it on the cloud?
>
> Do you take underground? What about being somewhere in it and there is just
> a subtle problem somewhere in the VmWare?

But then, just use one of the supported "bare metal" solutions. It has
never been said that bare metel would not be supported *at all*, has it?

The roadmap still has "full support for HPE DL380" for 9.2-x.

>
> I don't want to relaunch all the chat around virtual or not virtual. But it
> is just: yes there are use cases for bare metal. Minority? yes, not in the
> Bid Trend? yes. VSI is right on its choices? I'm not VSI.
>
> I heard on the last webinar VSI saying something like "if you realy need
> bare metal, call us and we'll see what can be done on specific hardwares".
> Not at all now a priority, but something can be done. Impossible to be
> microsoft or large linux community to support any hardware, but, yes,
> developping specific drivers could be done.
>
> You know there is a litterature about that for Vax, Alpha (perhaps itanium,
> I don't know). It is because it was possible for ISV to develop drivers for
> their products. I don't know how many did that. But it is a normal
> situation, and it is possible we'll have something like that for x86. VSI
> is thinking about a community with its -for-a-far-future- project Atom.
> Perhaps there will be another community for the -not-so-far-project
> developping some specific drivers for specific bare metal x86 VMS.
>
> Gérard Calliet
>>
>> Jan-Erik.
>>
>>>
>>> John
>>
>
>

On 13/05/2022 5:03 am, Jan-Erik Söderholm wrote:
> Den 2022-05-12 kl. 22:40, skrev Gérard Calliet:
>> Le 12/05/2022 à 21:22, Jan-Erik Söderholm a écrit :
>>> Den 2022-05-12 kl. 21:07, skrev John Dallman:
>>>> Listening to the latest webinar, it was mentioned that a common
>>>> question from customers was about support of specific
>>>> hardware. At that point, I realised that the variety of x86
>>>> server hardware currently available probably exceeds the total
>>>> variety of all the hardware that VMS has ever run on.
>>>>
>>>> Yes. All the variations of VAX, Alpha and Itanium that have
>>>> ever been supported likely provided less variety - in terms of
>>>> devices to support - than the variety of x86 server hardware
>>>> that's _currently_ available, ignoring all the x86 kit that is
>>>> no longer on sale, but still viable.
>>>>
>>>> How the hell is this managed for Windows and Linux? For those
>>>> OSes, the manufacturers do a lot of the work of writing and
>>>> testing device drivers. Microsoft have to do a lot themselves
>>>> for Windows, and also provide SDKs and templates. For Linux,
>>>> the big distributors, such as Red Hat, do quite a bit. There
>>>> are also consultancies that write drivers for manufacturers,
>>>> and/or provide training and SDKs.
>>>>
>>>> For VMS, at present, there's just VSI. They aren't a big
>>>> company and they have a lot of work to do without doing lots of
>>>> drivers. An obvious solution would be to switch to a
>>>> hypervisor-only support model, but it appears that many
>>>> customers want to work on bare metal.
>>>
>>> I thought that VSI said that the increast focus on VM
>>> environments is due to customer demands. As I understand, the
>>> major part of VSI income comes from customers where running in a
>>> VM is the prefered solution.
>>>
>>>>
>>>> I can't find any information on the VSI website about writing
>>>> device drivers. There might be an opening for a company who
>>>> produced device drivers for customers.
>>>
>>> I really can't see the need today. Just run in a VM and you have
>>> all the driver support you'll evr need. Special hardware that you
>>> might need to communicate with, is probably network/TCPIP
>>> connected anyway.
>>>
>>> So, I see no business case for custom written device drivers
>>> today.
>> Do you live near a nuclear plant? Do you think you would be pleased
>> to know the OS used to control it has part of it on the cloud?
>>
>> Do you take underground? What about being somewhere in it and there
>> is just a subtle problem somewhere in the VmWare?
>
> But then, just use one of the supported "bare metal" solutions. It
> has never been said that bare metel would not be supported *at all*,
> has it?
>
> The roadmap still has "full support for HPE DL380" for 9.2-x.
>
>
>

Or just do an Oracle and don't support (insure against) nuclear
reactors. And to our American friends that's not pronounced Knewklar

Le 12/05/2022 à 23:03, Jan-Erik Söderholm a écrit :
> Den 2022-05-12 kl. 22:40, skrev Gérard Calliet:
>> Le 12/05/2022 à 21:22, Jan-Erik Söderholm a écrit :
>>> Den 2022-05-12 kl. 21:07, skrev John Dallman:
>>>> Listening to the latest webinar, it was mentioned that a common
>>>> question
>>>> from customers was about support of specific hardware. At that point, I
>>>> realised that the variety of x86 server hardware currently available
>>>> probably exceeds the total variety of all the hardware that VMS has
>>>> ever
>>>> run on.
>>>>
>>>> Yes. All the variations of VAX, Alpha and Itanium that have ever been
>>>> supported likely provided less variety - in terms of devices to
>>>> support -
>>>> than the variety of x86 server hardware that's _currently_ available,
>>>> ignoring all the x86 kit that is no longer on sale, but still viable.
>>>>
>>>> How the hell is this managed for Windows and Linux? For those OSes, the
>>>> manufacturers do a lot of the work of writing and testing device
>>>> drivers.
>>>> Microsoft have to do a lot themselves for Windows, and also provide
>>>> SDKs
>>>> and templates. For Linux, the big distributors, such as Red Hat, do
>>>> quite
>>>> a bit. There are also consultancies that write drivers for
>>>> manufacturers,
>>>> and/or provide training and SDKs.
>>>>
>>>> For VMS, at present, there's just VSI. They aren't a big company and
>>>> they
>>>> have a lot of work to do without doing lots of drivers. An obvious
>>>> solution would be to switch to a hypervisor-only support model, but it
>>>> appears that many customers want to work on bare metal.
>>>
>>> I thought that VSI said that the increast focus on VM environments is
>>> due to customer demands. As I understand, the major part of VSI income
>>> comes from customers where running in a VM is the prefered solution.
>>>
>>>>
>>>> I can't find any information on the VSI website about writing device
>>>> drivers. There might be an opening for a company who produced device
>>>> drivers for customers.
>>>
>>> I really can't see the need today. Just run in a VM and you have all
>>> the driver support you'll evr need. Special hardware that you might
>>> need to communicate with, is probably network/TCPIP connected anyway.
>>>
>>> So, I see no business case for custom written device drivers today.
>> Do you live near a nuclear plant? Do you think you would be pleased to
>> know the OS used to control it has part of it on the cloud?
>>
>> Do you take underground? What about being somewhere in it and there is
>> just a subtle problem somewhere in the VmWare?
>
> But then, just use one of the supported "bare metal" solutions. It has
> never been said that bare metel would not be supported *at all*, has it?
Sorry, I was thinking you said there are not any use cases for bare metal.
>
> The roadmap still has "full support for HPE DL380" for 9.2-x.
One day.
>
>
>>
>> I don't want to relaunch all the chat around virtual or not virtual.
>> But it is just: yes there are use cases for bare metal. Minority? yes,
>> not in the Bid Trend? yes. VSI is right on its choices? I'm not VSI.
>>
>> I heard on the last webinar VSI saying something like "if you realy
>> need bare metal, call us and we'll see what can be done on specific
>> hardwares". Not at all now a priority, but something can be done.
>> Impossible to be microsoft or large linux community to support any
>> hardware, but, yes, developping specific drivers could be done.
>>
>> You know there is a litterature about that for Vax, Alpha (perhaps
>> itanium, I don't know). It is because it was possible for ISV to
>> develop drivers for their products. I don't know how many did that.
>> But it is a normal situation, and it is possible we'll have something
>> like that for x86. VSI is thinking about a community with its
>> -for-a-far-future- project Atom. Perhaps there will be another
>> community for the -not-so-far-project developping some specific
>> drivers for specific bare metal x86 VMS.
>>
>> Gérard Calliet
>>>
>>> Jan-Erik.
>>>
>>>>
>>>> John
>>>
>>
>>
>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Le 13/05/2022 à 04:24, Richard Maher a écrit :
> On 13/05/2022 5:03 am, Jan-Erik Söderholm wrote:
>> Den 2022-05-12 kl. 22:40, skrev Gérard Calliet:
>>> Le 12/05/2022 à 21:22, Jan-Erik Söderholm a écrit :
>>>> Den 2022-05-12 kl. 21:07, skrev John Dallman:
>>>>> Listening to the latest webinar, it was mentioned that a common
>>>>>  question from customers was about support of specific
>>>>> hardware. At that point, I realised that the variety of x86
>>>>> server hardware currently available probably exceeds the total
>>>>> variety of all the hardware that VMS has ever run on.
>>>>>
>>>>> Yes. All the variations of VAX, Alpha and Itanium that have
>>>>> ever been supported likely provided less variety - in terms of
>>>>> devices to support - than the variety of x86 server hardware
>>>>> that's _currently_ available, ignoring all the x86 kit that is
>>>>> no longer on sale, but still viable.
>>>>>
>>>>> How the hell is this managed for Windows and Linux? For those
>>>>> OSes, the manufacturers do a lot of the work of writing and
>>>>> testing device drivers. Microsoft have to do a lot themselves
>>>>> for Windows, and also provide SDKs and templates. For Linux,
>>>>> the big distributors, such as Red Hat, do quite a bit. There
>>>>> are also consultancies that write drivers for manufacturers, and/or
>>>>> provide training and SDKs.
>>>>>
>>>>> For VMS, at present, there's just VSI. They aren't a big
>>>>> company and they have a lot of work to do without doing lots of
>>>>> drivers. An obvious solution would be to switch to a
>>>>> hypervisor-only support model, but it appears that many
>>>>> customers want to work on bare metal.
>>>>
>>>> I thought that VSI said that the increast focus on VM
>>>> environments is due to customer demands. As I understand, the
>>>> major part of VSI income comes from customers where running in a
>>>> VM is the prefered solution.
>>>>
>>>>>
>>>>> I can't find any information on the VSI website about writing
>>>>> device drivers. There might be an opening for a company who
>>>>> produced device drivers for customers.
>>>>
>>>> I really can't see the need today. Just run in a VM and you have
>>>> all the driver support you'll evr need. Special hardware that you
>>>> might need to communicate with, is probably network/TCPIP
>>>> connected anyway.
>>>>
>>>> So, I see no business case for custom written device drivers
>>>> today.
>>> Do you live near a nuclear plant? Do you think you would be pleased
>>> to know the OS used to control it has part of it on the cloud?
>>>
>>> Do you take underground? What about being somewhere in it and there
>>> is just a subtle problem somewhere in the VmWare?
>>
>> But then, just use one of the supported "bare metal" solutions. It
>> has never been said that bare metel would not be supported *at all*,
>> has it?
>>
>> The roadmap still has "full support for HPE DL380" for 9.2-x.
>>
>>
>>
>
> Or just do an Oracle and don't support (insure against) nuclear
> reactors. And to our American friends that's not pronounced Knewklar
American humour? When something dangerous exists, just ignore it.
I thought it was just in australia where they believe in ostrich
politics. (french humour)

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Le jeudi 12 mai 2022 à 21:08:55 UTC+2, John Dallman a écrit :
> How the hell is this managed for Windows and Linux? For those OSes, the
> manufacturers do a lot of the work of writing and testing device drivers.
> Microsoft have to do a lot themselves for Windows, and also provide SDKs
> and templates. For Linux, the big distributors, such as Red Hat, do quite
> a bit. There are also consultancies that write drivers for manufacturers,
> and/or provide training and SDKs.
Linux mostly runs with kernel-mode device drivers in-tree, maintained alongside the kernel. Some hardware vendors who can't be bothered to upstream their stuff ship vendor kernels instead, which are (usually poorly maintained) forks of the kernel. There are also ways to write user-mode drivers for specific subsystems, like FUSE for file-systems and the Linux USB API, but no generic framework.

However, the reason why I'm posting (not an OpenVMS guy in the slightest) is that solutions exist in the open-source world to run drivers on foreign systems. Of note, NetBSD's rump kernel is a framework that essentially allows one to port unmodified NetBSD device drivers, file systems and network stack to run anywhere with a reasonable amount of glue code. Device drivers specifically have been ported to the Linux kernel, bare metal, GNU/Hurd... Other solutions include DDEkit for 2.6-era Linux device drivers, the HaikuOS network compatibility layer for FreeBSD network drivers and so on.

> I can't find any information on the VSI website about writing device
> drivers. There might be an opening for a company who produced device
> drivers for customers.

My point is that VSI doesn't necessarily need to write device drivers themselves and they can't realistically handle every PCIe card and USB device out there. Even just supporting all modern, server-grade equipment from the major server vendors is going to be an overwhelming task. Maybe they should look into porting device drivers from other operating systems instead. There are plenty of BSD-licensed drivers too, if licensing issues prevent them from touching GPL-licensed stuff. Personally I'd go with NetBSD's rumpkernel because it's written in C, it has a well-established track record and I don't see a technical reason why it couldn't handle OpenVMS when it can handle running in user-space for micro-kernel operating systems.

That being said, porting existing, battle-tested device drivers don't make them magically qualified to run on OpenVMS, which is also another potential bottleneck if VSI ports a framework that gives them a lot of drivers at once. That's probably fine for hobbyists, but untested or unqualified device drivers and paying customers with support contracts is not a good mix.

Jean-Baptiste.

On 2022-05-12, John Dallman <jgd@cix.co.uk> wrote:
>
> I can't find any information on the VSI website about writing device
> drivers. There might be an opening for a company who produced device
> drivers for customers.
>

The last public VMS device driver manual I am aware of is the one for
Alpha VMS. It is a book in its own right (just like the old Digital
Press books) and it is not a part of the VMS documentation set.

However, writing a device driver for VMS is an absolutely horrible
experience compared to how device driver development works on Linux.

My one and only VMS device driver was about 15 or so years ago when
I plugged a WinTV card into an AlphaStation so I could pull the teletext
data stream out of the video signal and display teletext pages under VMS.
(This was back when analogue signals were still being transmitted in the UK).

Since then, I have written multiple device drivers for bare metal, an RTOS
and for Linux, and I can tell you that if you are used to writing device
drivers on Linux, you are unlikely to want to do the same on VMS.

I certainly have no desire to ever write another VMS device driver.

On Linux, device drivers are nicely modular plug in kernel modules
which can be removed and inserted as many times as you want (provided
you don't crash the system first :-)).

On VMS, once you have loaded a device driver, you cannot unload it to
load a fixed version. You have to do a full system reboot and login
again before you can load a modified version of your driver.

There is no such thing as rmmod on VMS. :-( :-( :-(

On VMS, you are limited in the kinds of device drivers you can write
based on the public knowledge available and due to basic VMS design
limitations. For example, unlike on Linux, there's no way for you to
write a filesystem driver and then load it into the kernel.

The example VMS device drivers available to you are utterly useless once
you get past the really basic stuff. You get LRDRIVER and that's about it. :-(

Simon.

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

On 5/13/2022 8:26 AM, Simon Clubley wrote:
> On 2022-05-12, John Dallman <jgd@cix.co.uk> wrote:
>>
>> I can't find any information on the VSI website about writing device
>> drivers. There might be an opening for a company who produced device
>> drivers for customers.
>>
>
> The last public VMS device driver manual I am aware of is the one for
> Alpha VMS. It is a book in its own right (just like the old Digital
> Press books) and it is not a part of the VMS documentation set.

If you were a DEC customer paying for VMS MDDS (media and documentation
distribution service), then you got Lenny Szubowicz's driver book along with
the full documentation set.

--
-- Rob

On 05/12/22 20:08, John Dallman wrote:
> Listening to the latest webinar, it was mentioned that a common question
> from customers was about support of specific hardware. At that point, I
> realised that the variety of x86 server hardware currently available
> probably exceeds the total variety of all the hardware that VMS has ever
> run on.
>
> Yes. All the variations of VAX, Alpha and Itanium that have ever been
> supported likely provided less variety - in terms of devices to support -
> than the variety of x86 server hardware that's _currently_ available,
> ignoring all the x86 kit that is no longer on sale, but still viable.
>
> How the hell is this managed for Windows and Linux? For those OSes, the
> manufacturers do a lot of the work of writing and testing device drivers.
> Microsoft have to do a lot themselves for Windows, and also provide SDKs
> and templates. For Linux, the big distributors, such as Red Hat, do quite
> a bit. There are also consultancies that write drivers for manufacturers,
> and/or provide training and SDKs.
>
> For VMS, at present, there's just VSI. They aren't a big company and they
> have a lot of work to do without doing lots of drivers. An obvious
> solution would be to switch to a hypervisor-only support model, but it
> appears that many customers want to work on bare metal.
>
> I can't find any information on the VSI website about writing device
> drivers. There might be an opening for a company who produced device
> drivers for customers.
>
> John

With an open source OS, Linux, FreeBSD etc, the system probes
the hardware at boot time, against a background of probably
thousands of different hardware interface vendors and
manufacturers. All that knowledge is effectively shared between
the various OS's, developed and refined over decades. I can't
see how VMS could match that in any way, but perhaps one solution
might be to write a driver translation layer module, to connect
open source drivers to vms. That could be a volunteer effort, or
volunteer effort organised and with support from VSI.

It's easy to see why the the approach is for a VM usage, but
many will want to run bare metal and a VM in itself introduces
far more complexity, and possibility of bugs...

Chris

On 2022-05-13, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 5/13/2022 8:26 AM, Simon Clubley wrote:
>> On 2022-05-12, John Dallman <jgd@cix.co.uk> wrote:
>>>
>>> I can't find any information on the VSI website about writing device
>>> drivers. There might be an opening for a company who produced device
>>> drivers for customers.
>>>
>>
>> The last public VMS device driver manual I am aware of is the one for
>> Alpha VMS. It is a book in its own right (just like the old Digital
>> Press books) and it is not a part of the VMS documentation set.
>
> If you were a DEC customer paying for VMS MDDS (media and documentation
> distribution service), then you got Lenny Szubowicz's driver book along with
> the full documentation set.
>

Yes, I remember that (and I have my own personal copy that I bought
from a bookshop).

I was talking about the online documentation because that's where John
was looking above.

These days, what do support contract people get in their Itanium
documentation for writing device drivers and what will people get
for writing device drivers in their x86-64 VMS documentation ?

How applicable is the information in the Alpha device driver manual
for writing Itanium and x86-64 device drivers these days ?

I know there isn't going to be a new I&DS manual for x86-64. Is there
going to be a new device driver manual for x86-64 ?

Thanks,

Simon.

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

On 5/13/2022 1:37 PM, Simon Clubley wrote:

> These days, what do support contract people get in their Itanium
> documentation for writing device drivers and what will people get
> for writing device drivers in their x86-64 VMS documentation ?
>
> How applicable is the information in the Alpha device driver manual
> for writing Itanium and x86-64 device drivers these days ?
>
> I know there isn't going to be a new I&DS manual for x86-64. Is there
> going to be a new device driver manual for x86-64 ?

Lenny's book is still quite relevant today. The specific thing that
it documents is the non-MACRO-32 interfaces to device
driver and other executive routines. Those interfaces have not changed.

What *has* changed for X86_64 is that the SVAPTE is no more.
IRP$L_SVAPTE is no more.

In our experience, much use of IRP$L_SVAPTE was not actually a pointer
to a SVAPTE, but a generic pointer. That change is a mechanical replacement
to use IRP$Q_BUFIO_PKT.

For code that actually deals with SVAPTEs, the change is pretty code-specific.

Memory management is another area where port device drivers might need to be aware of changes,
due to X86-specific changes in memory management.

I cannot speak to the specifics of either the SVAPTE or memory management changes, since that's
not an area I was deeply involved.

--

-- Rob

On 2022-05-13 08:20:55 +0000, Gérard Calliet said:

> Le 13/05/2022 à 04:24, Richard Maher a écrit :
>>
>> Or just do an Oracle and don't support (insure against) nuclear
>> reactors. And to our American friends that's not pronounced Knewklar
> American humour? When something dangerous exists, just ignore it.
> I thought it was just in australia where they believe in ostrich
> politics. (french humour)

Not what I would assume. Most likely a reference to a Yale-educated US
politician known for certain mispronunciations and for a premature
accomplishment.

Your own and earnestly erudite postings can sometimes be just as
confusing to the average reader. To use a more recent metaphor and one
which may well be just as confusing to you, Darmok.

[I'm sure that at least some of my postings here read like gibberish, too.]

Returning to the usual discussions here in the comp.os.vms newsgroup,
DEC long excluded nuclear and life-critical environments from the
standard terms and conditions; what Oracle has done is not unusual.

More generally and to your earlier reference, existing nuclear and
SCADA control systems tend not to be upgraded, while new control
systems will be chosen among competing contemporary options.

Sites (still) using PDP-11 or VAX (real or emulated) hardware in 2022
is less an indication of a modern and robust market than of the
financial or bureaucratic or regulatory limitations around
qualification and re-qualification options available at these sites.

For those choosing now, there are various good options and approaches
available here for nuclear, SCADA, factory floor, and other such,
ranging from Windows to seL4 to VxWorks, and with many other good
choices available.

Whether OpenVMS x86-64 becomes anew another such option remains to be
determined. Though the current SaaS license may well discourage some
long-duration usage.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-05-13 20:12:46 +0000, Robert A. Brooks said:

> On 5/13/2022 1:37 PM, Simon Clubley wrote:
>
>> I know there isn't going to be a new I&DS manual for x86-64. Is there
>> going to be a new device driver manual for x86-64 ?
> Lenny's book is still quite relevant today. The specific thing that
> it documents is the non-MACRO-32 interfaces to device driver and other
> executive routines. Those interfaces have not changed.

It's a quite a good and well-researched book. But it's getting a little
old. The errata for Margie and Lenny's driver book is fairly extensive
too, based on the number of sticky-notes my copy has accumulated over
the years.

VSI hasn't indicated plans for new device driver documentation (or a
book update), though some sort of update or errata is undoubtedly
planned as V9 becomes established and as more folks start looking at
and creating device drivers.

The parallel page table implementation may well trip a few device
drivers, for instance. And which will probably mean more sticky-notes
added into my and into other copies of the driver book.

--
Pure Personal Opinion | HoffmanLabs LLC

On Friday, May 13, 2022 at 10:37:42 AM UTC-7, Simon Clubley wrote:
> On 2022-05-13, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
> > On 5/13/2022 8:26 AM, Simon Clubley wrote:
> > If you were a DEC customer paying for VMS MDDS (media and documentation
> > distribution service), then you got Lenny Szubowicz's driver book along with
> > the full documentation set.
> >
> Yes, I remember that (and I have my own personal copy that I bought
> from a bookshop).
>
> I was talking about the online documentation because that's where John
> was looking above.
>
> These days, what do support contract people get in their Itanium
> documentation for writing device drivers and what will people get
> for writing device drivers in their x86-64 VMS documentation ?
>
> How applicable is the information in the Alpha device driver manual
> for writing Itanium and x86-64 device drivers these days ?
>
> I know there isn't going to be a new I&DS manual for x86-64. Is there
> going to be a new device driver manual for x86-64 ?

I'd hope that the APIs haven't changed too much between Alpha and newer systems. They're all little-endian and 64-bit, after all.

One of my Twitter friends who likes collecting 1990's PCs has been writing Voodoo2 PCI drivers to port Glide to every OS that she can get her hands on.. She bought an AlphaServer DS10 last year, taught herself VMS, bought a used copy of the driver book you mentioned, and that was enough information for her to write a Voodoo2 driver and port Glide:

https://github.com/Luigi30/vms-glide
https://twitter.com/LuigiThirty/status/1395061216385581057

Incredibly impressive work, especially for one person who'd never used VMS before and was doing this port as an unpaid hobby project. It would've been more challenging still if this card required DMA or use of interrupts, but fortunately, it's "just" MMIO. She definitely had to buy the driver book in order to have the necessary info.

BTW, I know that a lot of POS systems use USB to connect to all the peripherals, and with a USB generic driver interface, which VMS has, you can talk to any of them without having to write a kernel driver. I haven't tested this, but the only weakness that I see from the docs is that they don't support isochronous pipes, so you wouldn't be able to talk to a USB audio device (not that there's a documented PCM audio driver API, after the retirement of MMOV for Alpha). USB generic support should be enough to talk to almost any other type of device as long as USB 2.0 is sufficient and you're on an Itanium (or x86).

Regards,
Jake

On 14/05/2022 4:50 am, Stephen Hoffman wrote:
> On 2022-05-13 08:20:55 +0000, Gérard Calliet said:
>
>> Le 13/05/2022 à 04:24, Richard Maher a écrit :
>>>
>>> Or just do an Oracle and don't support (insure against) nuclear
>>> reactors. And to our American friends that's not pronounced Knewklar
>> American humour? When something dangerous exists, just ignore it.
>> I thought it was just in australia where they believe in ostrich
>> politics. (french humour)

Don't worry, when we need to stock up on white flags we know where to go.

>
> Not what I would assume. Most likely a reference to a Yale-educated US
> politician known for certain mispronunciations and for a premature
> accomplishment.
>

That's him.

> Your own and earnestly erudite postings can sometimes be just as
> confusing to the average reader. To use a more recent metaphor and one
> which may well be just as confusing to you, Darmok.
>
> [I'm sure that at least some of my postings here read like gibberish, too.]

What do you me "too" :-)
>
> Returning to the usual discussions here in the comp.os.vms newsgroup,
> DEC long excluded nuclear and life-critical environments from the
> standard terms and conditions; what Oracle has done is not unusual.
>
> More generally and to your earlier reference, existing nuclear and SCADA
> control systems tend not to be upgraded, while new control systems will
> be chosen among competing contemporary options.
>
> Sites (still) using PDP-11 or VAX (real or emulated) hardware in 2022 is
> less an indication of a modern and robust market than of the financial
> or bureaucratic or regulatory limitations around qualification and
> re-qualification options available at these sites.
>
> For those choosing now, there are various good options and approaches
> available here for nuclear, SCADA, factory floor, and other such,
> ranging from Windows to seL4 to VxWorks, and with many other good
> choices available.
>
> Whether OpenVMS x86-64 becomes anew another such option remains to be
> determined.  Though the current SaaS license may well discourage some
> long-duration usage.
>
>
>

Le 13/05/2022 à 22:50, Stephen Hoffman a écrit :
> On 2022-05-13 08:20:55 +0000, Gérard Calliet said:
>
>> Le 13/05/2022 à 04:24, Richard Maher a écrit :
>>>
>>> Or just do an Oracle and don't support (insure against) nuclear
>>> reactors. And to our American friends that's not pronounced Knewklar
>> American humour? When something dangerous exists, just ignore it.
>> I thought it was just in australia where they believe in ostrich
>> politics. (french humour)
>
> Not what I would assume. Most likely a reference to a Yale-educated US
> politician known for certain mispronunciations and for a premature
> accomplishment.
>
> Your own and earnestly erudite postings can sometimes be just as
> confusing to the average reader. To use a more recent metaphor and one
> which may well be just as confusing to you, Darmok.
>
> [I'm sure that at least some of my postings here read like gibberish, too.]
We have a long way to be able to play with all of our idioms. Perhaps
being more classic, using only the authors used on the Internals
epigraph chapters? Or just Shakespeare's? We really to get a common
langage for the next boot camps :)
>
> Returning to the usual discussions here in the comp.os.vms newsgroup,
> DEC long excluded nuclear and life-critical environments from the
> standard terms and conditions; what Oracle has done is not unusual.
>
> More generally and to your earlier reference, existing nuclear and SCADA
> control systems tend not to be upgraded, while new control systems will
> be chosen among competing contemporary options.
You are right. I mentioned nuclear plants or human transportation just
to argue on examples where virtual seems inadequate. There are some.
>
> Sites (still) using PDP-11 or VAX (real or emulated) hardware in 2022 is
> less an indication of a modern and robust market than of the financial
> or bureaucratic or regulatory limitations around qualification and
> re-qualification options available at these sites.
1) your are right: not an indication of a robust market
2) bare metal can still be needed somewhere
3) relaunching a "legacy" ecosystem is perhaps another issue than just
searching for classic markets; classic markets are explored with classic
marketing and classic funding (billions) ; can VMS compete with classic
markets?
>
> For those choosing now, there are various good options and approaches
> available here for nuclear, SCADA, factory floor, and other such,
> ranging from Windows to seL4 to VxWorks, and with many other good
> choices available.
Right
>
> Whether OpenVMS x86-64 becomes anew another such option remains to be
> determined.  Though the current SaaS license may well discourage some
> long-duration usage.
Right
>
>
>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

>> Returning to the usual discussions here in the comp.os.vms newsgroup,
>> DEC long excluded nuclear and life-critical environments from the
>> standard terms and conditions; what Oracle has done is not unusual.

That's terrible! For years the PDP-8e was the standard controls machine
for nuclear power applications; the Nuclear Engineering department at Georgia
Tech continued teaching PDP-8 assembler well into the early 2000s.

Mind you where I work we replaced our PDP-8 that was doing wind tunnel
control with a PLC...
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <t5qo66$mlq$1@panix2.panix.com>, kludge@panix.com (Scott Dorsey) writes:
>>> Returning to the usual discussions here in the comp.os.vms newsgroup,
>>> DEC long excluded nuclear and life-critical environments from the
>>> standard terms and conditions; what Oracle has done is not unusual.
>
>That's terrible! For years the PDP-8e was the standard controls machine
>for nuclear power applications; the Nuclear Engineering department at Georgia
>Tech continued teaching PDP-8 assembler well into the early 2000s.
>
>Mind you where I work we replaced our PDP-8 that was doing wind tunnel
>control with a PLC...

That really blows! <rolleyes>

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-05-15 11:29:10 +0000, Scott Dorsey said:

>>>
>>> Hoff: Returning to the usual discussions here in the comp.os.vms
>>> newsgroup, DEC long excluded nuclear and life-critical environments
>>> from the standard terms and conditions; what Oracle has done is not
>>> unusual.
>
> That's terrible! For years the PDP-8e was the standard controls
> machine for nuclear power applications; the Nuclear Engineering
> department at Georgia Tech continued teaching PDP-8 assembler well into
> the early 2000s.

That's prolly related to much of the US nuclear power industry and
regulatory oversight being so utterly obdurate.

No new designs approved and online in how many years? There are a few
positive signs, with one SMR design only recently having gotten
approval for a lab install.

Last I checked, US Nuclear Regulatory Commission had never approved a
new reactor design and brought it into production in the entire history
of the agency since its formation in 1975.

Somebody needs to light a fire under that whole agency and under that
whole power generation industry, or our climate is far too soon going
to light a fire under all of us.

Yeah, I well understand safety. Competing power generation has... yet
bigger issues... there.

TL;DR: PDP-8 tech worked fine for our grandparents and great
grandparents, so it'll work fine for us.

--
Pure Personal Opinion | HoffmanLabs LLC

On 05/15/22 18:07, Stephen Hoffman wrote:
> On 2022-05-15 11:29:10 +0000, Scott Dorsey said:
>
>>>>
>>>> Hoff: Returning to the usual discussions here in the comp.os.vms
>>>> newsgroup, DEC long excluded nuclear and life-critical environments
>>>> from the standard terms and conditions; what Oracle has done is not
>>>> unusual.
>>
>> That's terrible! For years the PDP-8e was the standard controls
>> machine for nuclear power applications; the Nuclear Engineering
>> department at Georgia Tech continued teaching PDP-8 assembler well
>> into the early 2000s.
>
> That's prolly related to much of the US nuclear power industry and
> regulatory oversight being so utterly obdurate.
>
> No new designs approved and online in how many years? There are a few
> positive signs, with one SMR design only recently having gotten approval
> for a lab install.
>
> Last I checked, US Nuclear Regulatory Commission had never approved a
> new reactor design and brought it into production in the entire history
> of the agency since its formation in 1975.
>
> Somebody needs to light a fire under that whole agency and under that
> whole power generation industry, or our climate is far too soon going to
> light a fire under all of us.
>
> Yeah, I well understand safety. Competing power generation has... yet
> bigger issues... there.
>
> TL;DR: PDP-8 tech worked fine for our grandparents and great
> grandparents, so it'll work fine for us.
>

Of course it would. Much simpler architecture, small scale integration
logic devices, less memory and complexity in the software as well. All
contributes to reliability.

From what a dealer told me some years ago, pdp11/05 series were still
in use in UK nuclear stations decades after initial installation and
the two board cpu set was fetching a real premium due to scarcity...

Chris

On 2022-05-13, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 5/13/2022 1:37 PM, Simon Clubley wrote:
>
>> These days, what do support contract people get in their Itanium
>> documentation for writing device drivers and what will people get
>> for writing device drivers in their x86-64 VMS documentation ?
>>
>> How applicable is the information in the Alpha device driver manual
>> for writing Itanium and x86-64 device drivers these days ?
>>
>> I know there isn't going to be a new I&DS manual for x86-64. Is there
>> going to be a new device driver manual for x86-64 ?
>
> Lenny's book is still quite relevant today. The specific thing that
> it documents is the non-MACRO-32 interfaces to device
> driver and other executive routines. Those interfaces have not changed.
>
> What *has* changed for X86_64 is that the SVAPTE is no more.
> IRP$L_SVAPTE is no more.
>
> In our experience, much use of IRP$L_SVAPTE was not actually a pointer
> to a SVAPTE, but a generic pointer. That change is a mechanical replacement
> to use IRP$Q_BUFIO_PKT.
>
> For code that actually deals with SVAPTEs, the change is pretty code-specific.
>
> Memory management is another area where port device drivers might need to be aware of changes,
> due to X86-specific changes in memory management.
>
> I cannot speak to the specifics of either the SVAPTE or memory management changes, since that's
> not an area I was deeply involved.
>

Thank you for the update Rob.

For the benefit of those thinking about writing a VMS device driver,
including a more complex example would be very helpful for x86-64.

The examples I had in mind were the USB drivers and associated code.

They are a VMS version of driver and utility code that is available
in every other OS out there and people with Linux driver experience
(for example) could compare the VMS and Linux drivers to see what
is different and how to carry out those same driver tasks on VMS.

Simon.

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