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

[Stephen Hoffman]

On 2024-01-09 22:09:30 +0000, Lawrence D'Oliveiro said:

> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
> 
>> And again, what you are interested here in has been available for many 
>> years via Sector 7.
> 
> I’m not sure they did a comprehensive enough job. For instance, I 
> remember the previous time this came up, reading between the lines in 
> one of their case studies, the original customer scenario mentioned 
> using DECnet, but that was missiong from the description of the 
> solution.

In the traditional OpenVMS realm, porting apps to newer OpenVMS 
architectures has never been transparent, whether with DECmigrate or 
otherwise. Source code compatibility has been the goal, but full source 
compatibility wasn't ever achieved. (q.v. OpenVMS porting manuals)

Nothing on the order of the transparency provided by Rosetta or Rosetta 
2 has ever been available for OpenVMS.

As for DECnet networking, that's a sizable chunk of inner-mode code to 
make that work, whether in OpenVMS or in Linux using the now-deprecated 
DECnet code. OpenVMS uses an ACP and drivers, and provides an API known 
as VCI. It might be workable to re-create a non-IP network stack in 
user mode with some API at roughly the level of Linux (or OpenVMS) tap, 
though how well that might perform at links running at tens of gigabits 
per second and potentially faster? But for a user app being migrated 
off of OpenVMS, might as well migrate the networking to IP APIs while 
porting the code to the target Sector 7 environment.

Ain't nobody going to do a complete Sector 7 platform in one shot, 
either. APIs and itemcodes will get dribbled out as needed and 
available and tested, and the really obscure or arcane API usage stuff 
will get re-written or replaced within the apps.

More generally, I'd also wonder why anybody would target the Linux 
kernel for their kernel transplantation. Serious question. No insult 
intended toward Linux here, but any kernel transplant best considers 
all of the available open-source kernels, if the existing OpenVMS 
kernel is not going to be preserved. Why would anybody pick the Linux 
kernel for a transplant, over the other candidates? Picking Linux also 
means GPL compliance is involved, and that makes things interesting as 
VSI doesn't own full rights to the HPE-provided OpenVMS code.



-- 
Pure Personal Opinion | HoffmanLabs LLC