[FreeVMS] New enthusiast.

Guido guidoj2269 at gmail.com
Sat Jun 10 11:56:51 CEST 2017


On 06/08/2017 11:22 AM, Roar Thronæs wrote:
> I would say that it is not based on Linux 2.4.18 anymore, even though it is the
> newest kernel that was used.
> (If you compare the sources, you will find almost all of 2.4.18 missing.)
> It makes no sense upgrading the parts of the Linux kernel, since there
> is very little remaining of it.
> The major/important system calls in Linux just wrap to some
> minimal VMS functionality.
>
> So that means we are more or less on our own, and can not lean on Linux so
> much. (Aside from using Debian and related tools to build FreeVMS.)
>
> Newer Linux kernels may be used for borrowing hardware driver code,
> but I would not say that is important now.
> FreeVMS could for the time being live happily in some virtual machine,
> with minimal drivers.

The x86_64 support of the 2.4.18 linux kernel was lacking at best (would 
have required a 2.6.x kernel at least). I agree that upgrading the 
kernel makes little sense though (did investigate it some time ago, but 
discarded the idea). This means that with FreeVMS 0.3.x we are 
essentially stuck with (virtual) i386 based hardware. Though that should 
not be a problem for adding most VMS functionality, it would be a lot 
more appealing to develop for more contemporary hardware. Adding x86_64 
support is no small task either, because that bounds on developing some 
bare bones OS.

Borrowing driver code of newer kernels might prove unnecessary (because 
of the i386 only support) or difficult because of internal API changes 
within the linux kernel.

> Restarting would be very hard, it requires a person with a lot of competence
> and a lot of time available.

Competence and time are essential for any task :-)

> So I would go for 1. continue the 0.3.x branch unless someone with a lot
> of competence and a lot of time show up.

Continuing the FreeVMS 0.3.x branch will be a lot of work too. In its 
present state it seems to be thrown together without much consideration 
for design, making it difficult to comprehend.

>> 6. start with a compatiblity layer that enables you to recompile VMS
>>     software on Linux or Windows (to be incorporated the into FreeVMS)
> I am not able to evaluate this option.

It was just an idea I had. You could look at the examples from eight 
cubed (http://www.eight-cubed.com/examples.shtml) and get them to work 
by creating a layer consisting of (shared) libraries and/or modules so 
they can run without modification on linux (for instance). You can start 
with higher level service call functionality and work your way down from 
there. The examples can be extended/rewritten so they become system 
service tests and these tests can be verified by running them on a real 
VMS system. Many of the resources required for such a layer are already 
available as part of the FreeVMS code, although you should start with a 
better thought out design.

I am not saying that this will be less work than any other option, but 
it might result faster in something that at least partially works. If 
you want, you will be able develop such a layer in parallel to current 
FreeVMS branches.

Regards,
Guido



More information about the FreeVMS mailing list