Most of the time, when we refer to Unix and Linux migrations we are talking about moving from Unix to Linux. But...
what about the reverse scenario, moving from Linux to Unix? This raises a few questions: Why would someone want to port to Unix from Linux? What are some of the technical challenges in doing this kind of port? Where do we start?
Usually, organizations port their Linux applications to Unix for one of two reasons:
- The organization that owns and/or distributes the code needs to port their application to other environments that they either sell or support. This could be a reseller of some application whose customers insist that they port the code to their Unix platforms.
- They require maximum performance, reliability and/or virtualization capabilities. Although Linux has come a long way in recent years towards becoming an enterprise platform for the most mission critical of data centers, Unix is unquestionably a more mature operating system. The three main hardware distributors of Unix -- HP (HP-UX), IBM (AIX) and Sun (Solaris) -- continue to make Unix a key ingredient of their offerings.
- They package their hardware with Unix kernels and offer rock-solid, commercial-based support. Linux distributions, having also come up with some important virtualization innovations over the past year, are still perceived as lagging behind Unix in this important area. Also, a new CIO/CTO has come aboard. Users will insist on a port because they perceive Unix as the stronger option.
Take IBM's Unix flavor, AIX, for example. Unlike Sun's version of Unix, Solaris -- which is available on RISC and CISC platforms -- AIX is available only on IBM's RISC platform. AIX is based on the ATT System V UNIX operating system, though it has incorporated so many features from BSD that many consider it a hybrid of the two. IBM has considerably enhanced the OS to take advantage of its hardware and the many virtualization innovations in recent years. Linux, unlike AIX, does not conform to the IEEE Std 1003.1-2001 standard (POSIX) and has its own standards.
One reason users choose UNIX over Linux is greater endianness, a term that describes the ordering of memory used for data representation. Endian-neutral code does not have any dependencies on byte ordering and allows for greater portability between systems. Because most Linux users are running the OS on commodity based Intel hardware, there are already built-in challenges. AIX runs on System p servers, which are big-endian, while PCs are little-endian. We must first determine if the code is endian-neutral. In order for an application or a device driver to use the same source code base on both platforms, it must be endian-neutral. The exception is to use conditional compilation, selecting only appropriate code modules which are neutral. The only way to confirm this is to do appropriate User Acceptance Testing (UAT) to ensure that the application retains its functionality while being ported across different platforms.
32-bit or 64-bit?
Is the application 32- or 64-bit? If it's 32-bit, confirm that you want to stay 32-bit and also move it that way, as opposed to moving it to 64-bit. If the expectation is that you want to ultimately move to 64-bit, it should be a day-two activity. The first project would be porting the application to AIX 32-bit. Moving to 64-bit would be a separate project. Understand that moving from a 32-bit to 64-bit model is a development activity not a port. AIX systems can support either a 32-bit or 64-bit kernel. PCs support 32-bit kernels, while Itanium based systems only support 64-bit. The decision to further port to 64-bit depends upon the following:
- Will you be able to benefit from using more than 4GB of virtual address space?
- Can you benefit from more physical memory than 4 GB?
- Can you benefit from using 64-bit registers to perform 64-bit arithmetic?
Understand that with 64-bit applications, you will require more stack space to hold larger registers. More importantly, 64-bit applications will not run on 32-bit hardware platforms. Many folks prefer to keep their application 32-bit for this purpose alone, as it can usually run on 64-bit systems without any code changes.
Two big issues when converting 32-bit to 64-bit include data-type consistency, data models, and interoperation between applications using the different models. In a best case scenario, it is possible that the source may require only to be recompiled (while also relinking to 64-bit libraries). In a worse case scenario, code changes may be required.
There are typically six steps towards doing this kind of port:
- Analysis: This is where you do the homework, understanding the differences between your source and target. Issues such as endianness and 32-bit/64-bit should be addressed here.
- Preparation: This is where you configure your development environment to start building your application. This includes the use of makefiles and the type of shell you will be using.
- Compilation: Here is where you do the actual porting/compiling of the application.
- Testing: Getting the bugs out.
- Optimization: This is where you look at issues such as performance to make sure that the software runs at an acceptable level. Appropriate load and stress testing during this phase is extremely critical. You do not want to go into production with code that runs slow and is not optimized.
- User Acceptance Testing (UAT): Here is where you have real users banging away at the system to ensure that the functionality works.
Regarding enhancements, I prefer to make these day-two activities. Another day-two activity (for software distribution companies) is considering how to roll-out the application in a form of a package, for installation purposes. This would be done for companies that must distribute software to multiple clients. For instance, do you want them to do an install with standard AIX commands, such as installp, or with more traditional Unix commands?
Up to now, we've discussed the reasons to do a port, the larger issues to look for, and the overall methodology. What about tools? What does IBM offer to Linux developers to help port their application over?
AIX Toolbox for Linux applications
To assist with your porting needs, IBM provides the AIX Toolbox for Linux Applications. This system delivers installable open source tools to help you facilitate the recompilation of open source software - -oftentimes without modifications -- on AIX systems. The AIX Toolbox helps with building and packaging Linux applications on AIX; developing new applications for AIX using GNU and Linux development tools; running open source software found on Linux; and managing software using RPMs. It also includes the following:
- Application Development: gcc, g++, gdb, rpm, cvs, automake, autoconf, libtool, bison, flex, gettext
- Programming Languages: guile, python, tcl/tk, rep-gtk
- Libraries: ncurses, readline, libtiff, libpng, libjpeg, slang, fnlib, db, gtk+, qt
It's important to note that Linux applications being recompiled to run on AIX 5L must be written using standard Linux APIs and use the GNU gcc and g++ compilers. Two final points to consider:
- Because Linux can run natively on IBM POWER architecture, some companies that only wanted to port to AIX to take advantage of IBM's hardware can now do so by creating a Linux partition on the System p and installing their Linux applications. Some important benchmarks have been recently met. For example, in the SPECfp_2006 benchmark, a 4.7 GHz POWER6 processor in an IBM System p 570 server running SUSE Linux scored 22.4, the highest result in the industry, approximately 23% better than an HP Integrity rx6600 running HP-UX (18.1). If you want to go this method, understand that you may also have endian issues. Not all Linux applications that run on Intel servers are certified to run on IBM's System p. To address this, IBM has started a new initiative: IBM System p Application Virtual Environment. This will allow the user to run most x86 Linux applications on a System p without a recompile. The initiative is still in Beta at this time.
- Beginning with AIX 6, the AIX operating system will simplify its kernel environment by providing only the 64-bit kernel. AIX 6 will maintain application binary compatibility with previous AIX versions as specified above, but device drivers and kernel extensions that are 32-bit only will not be supported on AIX 6.
About the author: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist.