[Info-vax] Kernel Transplantation (was: Re: New CEO of VMS Software)

[Stephen Hoffman]

On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:

> On Fri, 5 Jan 2024 19:59:12 -0500, Stephen Hoffman wrote:
> 
>> [lots of interesting stuff omitted]
>> 
>> From another time and place, a DEC Usenix paper from way back in 1992 
>> discussing a kernel-swap project:
>> http://fossies.org/linux/freevms/doc/Usenix_VMS-on-Mach.PS
>> 
>> From a reference to that work: "In 1992, a development team from 
>> Digital Equipment described a proof-of-concept implementation of VMS on 
>> Mach 3.0. ... Their work provided independent confirmation that 
>> multiple OS personalities could be supported on the Mach microkernel. 
>> At the same time, it exposed certain limitations. For example, it 
>> proved impossible to accurately emulate VMS scheduling policies using 
>> Mach.
> 
> That can be blamed on the limitations of Mach. People still seem to 
> think microkernels are somehow a good idea, but they really don’t help 
> much, do they?

Every choice made in an OS is a trade-off. Every one.

There are OS and hardware trade-offs in every design, every era, every 
generation.

And the trade-offs vary over time and place. 1992 was VAX.

With current hardware including cores and performance and with newer 
message-passing designs such as OKL4 and ilk, some things are looking 
rather better.

>> As another example, it was not possible to emulate VMS’ strong 
>> isolation of kernel resource usage by different users.
> 
> Would the Linux cgroups functionality (as commonly used in the various 
> container schemes) help with this?

No.

Designers of VAX/VMS chose a memory management model closer to that of 
Multics, where much of the rest of hardware and software in the 
industry diverged from that lotsa-rings memory management design.  
Memory management designs with more than rings have largely disappeared 
in the ensuing decades, with Itanium being one of the most recent 
examples. x86-64 sorta-kinda has four rings, but the page table and 
ring design was too limited for OpenVMS expectations, and VSI is 
accordingly (and creatively) using two page tables to provide the 
necessary modes.

Containers are arguably fundamentally about product-licensing 
arbitrage, too. But it's not a foundation for a kernel transplantation.

>> Preliminary measurements also suggested that layering VMS on Mach 
>> resulted in unacceptable performance overhead.
> 
> No big surprise -- microkernel trouble yet again.

Mach on VAX in 1992, yeah. Microkernels are in use all over the place 
nowadays, seL4-, L4-, and OKL4-derived. And hardware performance has 
improved over the decades, and core counts are far higher than VAX era.

https://docs.sel4.systems/projects/sel4/frequently-asked-questions.html

Other deployments? Apple is using their own L4 derivative throughout.

Compare a 1992-era VAX to a 2023-era smartphone with 6 cores, 8 GB 
memory and a terabyte of persistent storage, and with vastly better 
graphics and networking. In a server design with similarly-modern 
heterogeneous processor hardware, the efficiency cores would likely be 
running batch and baggage, too.  VAX SIMH on a smartwatch probably runs 
decently well too, save for the woefully inadequate UI.

For a small development team—and VSI is tiny—kernel transplantation 
doesn't gain much from a technical basis, once the platform port is 
completed. It might help with future ports, sure. Ports (including 
transplantations) more generally are entirely disruptive, and delay 
other userland work and userland enhancements. And the kernel 
transplantation still requires ongoing maintenance and support and 
updates and releases as the new "host" kernel is modified by the 
outside vendors.  From another vendor doing this:

https://www.chromium.org/chromium-os/chromiumos-design-docs/chromium-os-kernel/

>From a business perspective, what Sector 7 offers is an easier and 
incremental off-ramp from OpenVMS to else-platform. Which is not going 
to be popular roadmap choice for the folks at VSI. And I'm somewhat at 
a loss for what the transplantation offers users.

Would I like to see a more modern kernel design underneath OpenVMS? 
Sure. But pragmatically, that's all way, way, way, way, way down the 
priority list for an ISV or third-party developer or customer. Or at 
VSI, by all appearances. And that new design will be 
userland-disruptive. Just as userland-disruptive as a port, if not 
larger. Booting OpenVMS as a guest on x86-64 gets rid of most of the 
longstanding customer hardware issues. And VSI isn't nearly well-funded 
enough to create a new OS both with easier portability for existing 
OpenVMS apps, and with enough new work and new features to draw in new 
customers—that's a decade of work and a chunk of a billion dollars just 
to get going. Got a bored billionaire handy that wants to take on 
~everybody with a new RISC V supermicrominikernel megaOS product with 
extra added OpenVMS flavor? Have at. Lemme know too, as that sounds 
like a fun project.


-- 
Pure Personal Opinion | HoffmanLabs LLC