[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