[Info-vax] CRTL and RMS vs SSIO

[Stephen Hoffman]

On 2021-10-12 21:39:17 +0000, Lawrence D’Oliveiro said:

> On Wednesday, October 13, 2021 at 9:54:14 AM UTC+13, Stephen Hoffman wrote:
>> The DEC OpenVMS advanced development group did do a prototype of 
>> OpenVMS on Mach a ~quarter-century ago.
> Yeah, but Mach is a microkernel, with all the downsides that microkernels have.

Mach is an old microkernel, and techniques have improved markedly (q.v. 
L4 family, etc)

Whether the performance limits from Mach message-passing from ~25 years 
ago with those designs are even still applicable to modern hardware is 
a discussion.

>> More recently, a similar starting point might be from seL4 or 
>> DragonflyBSD. If you're going to invest the effort and swap the kernel, 
>> might as well swap the existing kernel for a newer design.
> 
> The trouble with the BSDs is that they do not have compatible kernels. 
> So even though there are only a handful of BSD variants, it is 
> difficult to port kernel-level enhancements between them. While there 
> are something like 350 Linux distros and counting, they do share the 
> same common kernel codebase (and nearly all of the userland too, just 
> dressed up differently).

I'm aware of how Linux is structured and packaged.

Whatever alternative kernel might be chosen, VSI would still need to 
comply with the software licenses.

As for scale, most or all of the major BSDs each have massively larger 
deployments than does OpenVMS.

>> Downside of any kernel-swappage is that you pretty quickly then own the 
>> kernel you're working with; just as soon as you have to start modifying 
>> the kernel to better fit OpenVMS and OpenVMS app expectations.
> 
> Try to avoid that.

I am not so foolish as to fork without cause.

>From my time in the OpenVMS kernel, I don't believe that a clean 
re-hosting of the kernel onto the Linux kernel is possible without 
Linux kernel modifications or a whole lot of work in the rest of 
OpenVMS and the apps.

> Also remember that the VMS apps are legacy apps; you are trying to 
> maintain existing functionality, rather than take them in new 
> directions.

If you got that impression, you utterly misread the reply. If the 
effort to re-host is underway, why re-host to Linux and not to a more 
modern kernel design?

Also see previous discussions of and documentation for DEC MICA for 
what once could have been, and for what became possible else-platform.

> Major new development would be better off being Linux/POSIX-native.

That work can happen over on Linux, or seL4, or BSD, or whatever 
platforms the developers might choose among those that the vendors 
might offer.

>> Possible areas where kernel modifications might necessary? Linux memory 
>> management is thoroughly two-ring, and OpenVMS expectations are 
>> four-ring. Do you drop those areas from OpenVMS, and force app source 
>> code changes?
> Where is there app code that cares about this?

Apps that work with memory page protections, user-written system 
services, logical names and the various modes, RMS file access and 
channel modes, and various apps that use $cmexec or $cmkrnl calls, 
among others. This ignores user-written device drivers and execlets, 
which are also in use on a number of OpenVMS systems. As for VSI code, 
the OpenVMS debugger has been dependent on page protection shenanigans 
for breakpoint support, for instance—how that now works on x86-64, I've 
not checked.

Many of the apps presently hosted on OpenVMS do tend to be tied to the 
platform in various less-than-entirely-portable ways.

>> Other considerations awaiting VSI developers: any hypothetical chunks 
>> of OpenVMS linked against Linux, seL4, or some of the other kernels 
>> necessarily involves working within GPL2, which means VSI must write 
>> all of that source code themselves, and must then release it.
> 
> Oracle vs Google notwithstanding, it has long been the position in most 
> of the open-source community that APIs are not copyrightable.

That's not at all what I am referring to with that.







-- 
Pure Personal Opinion | HoffmanLabs LLC