From: Allan Schaffer (allan++at++sgi.com)
Date: 12/20/2000 12:59:13
On Dec 20, 11:13am, Narasimha Swamy T R wrote:
> We have to port an application working on Octane IRIX 6.5 to
> PC-Linux. The application is related to medical scanner and has
> a lot of OpenGL and X calls. The application has a lot of Unix system
> calls and also uses a lot of resources (like RAM). The application
> size is about a million lines of code.
>
> We wish to know what are the points that we have to consider
> before starting the porting work. We want to first do an estimate of
> effort and time.
[Is this a Performer-based application? If not, this isn't the right
mailing list. But the question is general enough to be of interest
to Performer developers undergoing similar porting projects, so...]
This is a very broad question so as you might expect one can only
give a broad-based reply. Performer is roughly the same size and
also uses a lot of OpenGL & X calls, with fairly complicated memory
management as well. :-) So they are similarly scoped projects.
In my opinion it's not difficult to port applications from one UNIX
variant to another, but the process _is_ difficult to scope &
estimate because progress occurs at a very irregular pace.
IRIX and Linux are similar in terms of adherence to common UNIX
development methodologies -- header files are similar, system
libraries are similar, standards used are similar, etc.
The big-picture differences you'll run into are:
1. Endianness. MIPS and INTEL are opposite-endian so 'binary'
data representations are not directly commutative between the two
-- you'll have to write translation routines to flip the bits
around, and to be very careful to identify all the cases where
translation is needed (and only those cases)
2. IRIX-specific functionality not present in Linux. Scoping this
will mean a detailed analysis of your code base. IRIX contains a
number of high-end/advanced/value-add system calls that does not
exist in Linux.
3. Hardware-specific OpenGL extensions. A perfectly-coded OpenGL
application uses compile-time #ifdef Extension_Name/#else/#endif
and run-time routines like glXQueryExtension to determine if
particular extensions are present, and falls back to alternate
functionality if they are not. You'll need to do this.
4. Dependence upon 3rd-party libraries. This is similar to item
#2, if your application is dependent upon libraries that you
don't have source code for, and haven't been ported to Linux yet,
you have to implement an alternative or rewrite your code to use
a similar library.
5. Build environment. Once the code is looking good this becomes
the real hassle! Hopefully you already have a fairly simple
build environment.
6. (Minor) Bugs. IRIX & Linux are forgiving in different ways about
application bugs; e.g. an uninitialized variable in IRIX can be
harmless but Linux behaves quite differently. Dereferencing NULL
happens to be allowed [unfortunately] on an Octane but would
crash elsewhere. Tracking these sorts of bugs down can be
difficult, since they "work fine" on one platform but not the
other.
In our case, we had the first 'spinning geoset' up & running about 2
weeks after starting the port of Performer to Linux. Once things get
rolling and you identify the parts to stub out and re-address later,
it all goes very quickly, except when it doesn't. :-)
Allan
-- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Wed Dec 20 2000 - 12:59:33 PST