|
|
| Author |
Message |
< Erlang-DACH ~ Porting Erlang to OpenVMS (I64) |
| JohnApps |
 Posted: Thu Mar 25, 2010 8:53 am |
 |
|
|
Joined: 25 Mar 2010
Posts: 1
|
Introduction
The following is a brief report on porting Erlang to OpenVMS running on I64 (Integrity Server). The work was performed by Brett Cameron of HP who also wrote most of the following. My role in the port was one of documentation and testing, both ongoing work.
The Approach
The basic approach I took was to configure and build Erlang on a UNIX system (Solaris as it happens) and to capture a log of the build process. To keep things reasonably simple, I did not go for the SMP build, and I also deliberately excluded a few other optional components from the build that I did not want or need on OpenVMS or that I knew would make the port even more complex.
Compiling and Linking using OpenVMS Scripts
I then took the log of the build and incrementally converted this into equivalent OpenVMS script (DCL) commands. Note that I probably could have used GNV (Gnu Not VMS), but it is not really good enough yet to be a huge help, and frankly I’d rather do things in a "pure" OpenVMS environment so as not to mask anything in any way. At this time I also looked at the “config.h” file created during the UNIX build and modified it as appropriate for OpenVMS.
Note also that I used simple command procedures (scripts) to compile the code, as opposed to attempting to construct MMS (make) scripts. This is to some degree personal preference, but also because in the initial stages of the port I wanted to be sure to recompile everything and to make sure that I had not missed anything. Erlang is a substantial code base!
Adjusting for OpenVMS Specifics
Once an initial (partial) build procedure was set up, I systematically started working through trying to compile up the code base, fixing compiler errors, sorting out include paths, eliminating warnings, and so on. At this point most of the trivial porting issues come into play, e.g., differences in header files, missing CRTL functions, and so on, and it is a case of working through these issues and addressing them as appropriate.
Having done such things quite a few times in the past (and wishing I’d made notes), it did not take too long to at least get most of the code to compile and link.
As a next pass, I searched through the code for known issues such as trying to use fcntl() to set sockets to non-blocking and incrementally addressed these. Getting pipes to work correctly and dealing with fork()/exec() sequences required a little more thought.
Adapting to the OpenVMS File System
The last hurdles to overcome were file-system related. It was reasonably easy to determine where the problems were in the C code, but when problems were at the Erlang level, they took me a little more time to resolve (not being particularly familiar with Erlang).
Making OpenVMS 'look' like UNIX
One thing I should note is that in order to avoid having to make excessive changes to any of the Erlang (erl) run-time libraries, I “made” OpenVMS look like a variant of UNIX. This means that wherever the Erlang checks the operating system type it thinks it’s UNIX, and it doesn’t much care (except in a small number of cases) what the specific variant is.
Testing
Most of the testing performed was using RabbitMQ which was quite easy to port. It ships with a number of very comprehensive test suites, some of which being in Java. We used the Java programs for the obvious reason that Java runs everywhere, which it did just fine on OpenVMS. We were able to uncover quite a few items requiring attention, the two most prevalent being the file-system and the method by which the main process communicates with its daemons: OpenVMS mailboxes. Whilst these are relatively fast, they were never designed for very high-speed messaging and so their use led to considerable resource usage on the machine.
Summary and next steps
So, with some effort we are at the point where we can compile Erlang code and we can run significant Erlang applications such as Yaws and RabbitMQ. The port is still far from perfect, but it generally works quite well.
Probably the area requiring most immediate attention would be how pipes are used to communicate between sub-processes. On OpenVMS pipes equate to mailboxes, and while they are generally very efficient, with products such as RabbitMQ the volume of I/O being pumped around can become an issue. That being said, addressing this matter will not be trivial. The other thing that needs to be done is to create an installation kit of some description. This should not be particularly difficult to do, and I’ll hopefully get around to it soon!
BC&JA (http://www.johndapps.com/) |
|
|
| Back to top |
 
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
