Porting from IRIX to Linux

Coding for portability to Linux: examples from the ACRT land vehicle port.

Linux is a superset of the POSIX
(Portable Operating System Interface for X) specification. It runs
on commodity PC hardware, MIPS systems, Suns, Macintoshes and even
IBM mainframes. It's sufficiently UNIX-like that much UNIX code can
be ported over with little change.

The Advanced Concepts Research Tool (ACRT) is a descendant of
the ARPA Reconfigurable Simulator Initiative (ARSI). It's primarily
IRIX but has NT versions for many of its modules. ACRT is a vehicle
simulator that can be reconfigured into different vehicles.
Raytheon supplies the land vehicle simulators, which currently are
the M1A1 and M1A2 tanks, M2 armored personnel carrier, M113, M577,
HMMWV and the Future Scout. Reconfigurability is done by using
“Erector Set”® type hardware, soft panels for controls,
serial line inputs for grips and a common set of core
software.

The Erector Set hardware looks like a scaled-up version of
its namesake. This allows the crew seats, controls and monitors
that can be placed in a variety of positions to emulate the vehicle
interiors.

We use the term soft panels to refer to touch-screen
activated control panels that are used in place of the real buttons
and switches in the actual vehicles. These are designed to place
the controls as close as possible to the real vehicle. This
minimizes the amount of hardware that is vehicle-specific
(currently only grips).

Grips are either actual crew station hardware from the
vehicle or copies with simplified interior wiring. These provide
switches and analog outputs used to control some vehicle functions.
The outputs from these are converted to voltages in the range of
zero to five volts DC and fed through a BG Systems Cereal Box. The
Cereal Box acts as an analog to the digital converter and feeds
values through serial lines to the host computer. Finally, the core
set of software used by all vehicles makes it easier to develop a
new vehicle or modify existing vehicle-specific modules.

At startup, the system runs different software modules on
different hosts. These different modules include things like ground
motion (how does the vehicle move), weapons models (how does a
weapon behave, where does the round go) and control panels for the
crew to interact with. The system is kicked-off from a single host
and then starts up process managers (host_mgr) on other hosts
through the UNIX rsh command.
These host_mgr processes then parse through configuration files to
see what runs on their local host.

The system uses message passing to move information between
the different modules. Between modules on the same host, the
messages are buffered in a memory-mapped file as a form of shared
memory. Between hosts, UDP sockets are used to pass information. A
gateway system translates between Defense Interactive Simulation
(DIS) messages and the internal vehicle messages. This allows the
simulator to interact with other simulators using the DIS protocol
(see Figure 1).

Figure 1

Objectives:

A) Demonstrate an image generator using Performer Linux
(Mongoose)

What started this project was SGI's release of its Performer
visualization/simulation tool for Linux (this version is called
“Mongoose”). Since our simulator's image generator (the part of
the system that draws the out-the-window and sensor views) is based
on Performer, the largest part of the work for a Linux port was
done for us. What remained was to port the code that used
Performer, the libraries and tools common to all vehicles (known as
the Tiger core), and enough of the vehicle so that it can interact
with its environment (to move, see other vehicles and utilize
special effects like weapons fire and detonation).

B) Dual-compile whenever possible to shrink codebase

To make it easier to maintain, we decided to maximize the
amount of code that would compile under either IRIX or Linux. This
shrinks the codebase to a more manageable size. The theory is that
each module would have a directory containing source code and under
it would be subdirectories for architecture-specific items
(compiled object files, libraries and executables). A Makefile in
with the source files uses the OSNAME environment variable to
bounce any make commands to the
correct subdirectory depending on the architecture of the host (see
Figure 2).

Figure 2

C) Arrange files so that machines of different architectures
use the same directories

To keep the configurations as similar as possible across
platforms, the files are arranged so that machines of different
architectures use the same directories. For distinctions that can
be made at compile time, there are different directories for
compiled libraries with which modules link and where the
executables are kept. Using environment variables for the BIN and
LIB directories that incorporate the architecture name can help
with that. For instance, on the IRIX systems, the binary directory
(stored in $ARSI_BIN) might be
/apps/projects/ACRT/bin/IRIX64. On Linux
systems, it might be
/apps/projects/ACRT/bin/Linux. Since the path is
stored in the same environment variable, scripts and Makefiles can
use it without regard for which type of system they are running
(see Figure 3). Environment variables are also available at runtime
to allow code to make decisions that can't be made at compile time.
By embedding environment variables in configuration files, we can
use the same configuration file for different architectures.

Figure 3

Portability of source files was an issue for the include
files and modules that dual-compiled IRIX/NT. For IRIX to use the
files, they had to be in UNIX format (the CR/LF issue) instead of
DOS format. Fortunately, MS Studio accepts files in UNIX format, so
we settled on that. Adding Linux didn't change this equation since
Linux handles both DOS and UNIX formats. Note, however, that shell
script files must be in UNIX format.

D) Overcome incompatibilities

We first tried to use POSIX functionality. When that was not
applicable, we opted for the greatest common denominator.

E) Simplify maintenance

To keep maintenance simpler, we tried to avoid convoluted
#ifdef-ed regions of code, be careful about variables used and set
in each branch of code and verify that the flow of control was not
drastically different between branches. When possible, #ifdef-ed
code was moved to a separate file to minimize the scope of its
effect on variables.

Finally, different compilers are sensitive to different
things. A condition that goes unremarked on one compiler may cause
a warning on another. Investigate and understand your compiler's
warnings. They may lead you to an error (in which case it's easier
to fix at compile time than to track down at runtime). Warnings may
show you where intent differed from implementation. Warnings can
also hide errors. Picking out the serious message in the midst of a
page of warnings about unused variables is harder than taking out
the unused variables.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.