Linux on power: Considerations for release version migration and binary compatibility

Measure the test taker's knowledge about binary compatibility and Its Relationship with different operating environments running on Linux on power. Measure the test taker's knowledge about the binary compatibility between two IBM Linux on power releases, Red Hat Enterprise Linux (RHEL) and SuSE Linux Enterprise Server (sles. In general, stable application binary interface (ABI) maintained between versions can be used to smoothly migrate from RHEL4 Based on 2.6.9 kernel to rhel5 Based on 2.6.18 kernel. This method also applies to migrating from kernel 2.6.5 to kernel 2.6.16 based sles10. Understand how to improve Linux on power applications ProgramAnd follow some steps to ensure the binary compatibility between multiple releases in the future. ["References" section provides additional reference content-Edit.]

There are many available Linux distributions. Although red hat and SuSE Linux are IBM-supported Linux on power solutions vendors, other releases (such as Gentoo, Debian, and UBUNTU) are becoming popular Linux on power solutions. Applications generally prefer to ensure that their applications can run on multiple releases and different versions of the same release. After understanding the issues related to binary compatibility, you can achieve these goals. This article defines binary compatibility, discusses considerations for maintaining compatibility, and discusses migration between different versions, including Red Hat Enterprise Linux versions 4 and 5, SuSE Linux Enterprise Server versions 9 and 10. In addition, it provides practices to ensure compatibility between applications across multiple releases.

Table 1 shows the software level and the features supported in RHEL4, rhel5, sles9, and sles10 that will be discussed in detail in this article:

Table 1. supported features and release versions of RHEL and slesCodeLevel

	Sles8 SP4	Rhel3 U4	Sles9 SP3	RHEL4 u8	Sles10 SP2	Rhel5 U3
Kernel	2.4.21	2.4.21	2.6.5	2.6.9	2.6.16	2.6.18
Glibc	2.2.5	2.3.2	2.3.3	2.3.4	2.4	2.5
SMT	No	No	Yes	Yes	Yes	Yes
Nptl	No	No	Yes	Yes	Yes	Yes
NUMA	No	No	Yes	Yes	Yes	Yes
JDK	IBM 1.3.1	IBM 1.4.2 release	IBM 1.4.2	IBM 1.4.2	IBM v1.4.2, 5.0	IBM v1.4.2, 5.0
Apache	1.3.26	2.0.46	2.0.49	2.0.52	2.2.0	2.2.3
Gcc	3.2	3.2.3	3.3.3	3.4.6	4.1.2	4.1.2

¹ You can download IBM developer kit for Linux and Java technology edition from the IBM site. (The References section provides links ).

Use the flowchart shown in figure 1 to determine whether the application is Binary compatible with RHEL or sles.

Figure 1. Determine the binary compatibility of the application

Binary Compatibility Overview

The binary compatibility of Linux on power is achieved by following the application binary interface (ABI. Abi is an interface through which compiled binary files access the operating system and services. When multiple operating environments support the same Abi, you can run the same binary file in these operating environments. You can find the information about PowerPC executable and linking format (ELF) in "64-bit PowerPC elf application binary interface supplement 1.7) for more information, see the Documentation Section ).

Binary Compatibility is the ability to run binary files in multiple environments of a specific processor series. These environments may be different versions of the same Linux release, or different versions. For example, a system running sles10 based on a power6 processor can compile and run binary files on a system running sles10 based on a power5 processor. Another example is to run binary files that can be compiled and run on a power5 processor-based system that runs sles10 and runs RHEL4.

Processor compatibility

Processor compatibility is closely related to the binary compatibility of Linux on power. This section discusses compatibility between 64-bit power processors and between 32-bit PowerPC processors and 64-bit power processors.

Power processor compatibility

The last example discussed in the "binary compatibility overview" section involves running the same binary file on two different processor types: power5 processor and power6 processor. The power6 architecture is an improvement of the power5 architecture while maintaining compatibility with power5, which allows you to run the same applications on both platforms.

Compatibility between PowerPC and power processors

The 32-bit application running in the 32-bit PowerPC environment and 64-bit power environment can also achieve binary compatibility. A 32-bit binary file generated on a 64-bit Linux on power system can be executed in the Linux PowerPC environment on the local machine. This compatibility can be achieved because:

• The 64-bit power architecture supports a complete 32-bit PowerPC architecture.
• The 64-bit Linux kernel can handle 32-bit system calls.
• The 32-bit runtime environment contains the necessary 32-bit libraries.
• The 64-bit runtime environment contains the necessary 32-bit and 64-bit libraries.

You can generate 32-bit and 64-bit Linux binary files in different ways, depending on the Development Platform:

• The GNU Compiler Collection (GCC) C editor on a 32-bit PowerPC platform (such as Apple PowerBook running Linux) can generate a 32-bit platform on the local machine, or a 32-bit binary file executed on a 64-bit Linux on power platform that contains an appropriate 32-bit user space library.
• Ibm xl c/C ++, version 8.0, and the gcc C compiler for 64-bit Linux on power can generate 32-bit and 64-bit binary executable files, these files can be executed in a 32-bit or 64-bit runtime environment.
• There are also cross-system compilers that can run on both 32-bit PowerPC Linux and 64-bit Linux on power systems. These cross-system compilers can generate 32-bit and 64-bit binary files. No matter where binary files are built, 32-bit binary files can be run on a 32-bit Linux platform or a 64-bit Linux platform, the generated 64-bit binary file can only run on the 64-bit Linux on power system. An example of a cross-system compiler is crosstool (reference ).

Table 2 shows how to generate 32-bit and 64-bit Linux binary files for different development platforms:

Table 2. Generate 32-bit and 64-bit Linux binary files

Development Platform	Compiler	Generated Linux binary file
32-bit Linux on powerpc	Local gcc C Compiler	32-bit
64-bit Linux on power	Local xl c/C ++ or gcc C Compiler	32-bit or 64-bit
32-bit Linux on powerpc or 64-bit Linux on power	Cross-system compiler, such as crosstool	32-bit or 64-bit

Although the compatibility between 32-bit and 64-bit environments has been demonstrated, this does not mean the official release supports this compatibility. Red Hat supports 32-bit and 64-bit compatibility between rhel3 and RHEL4. when migrating from sles8 to sles9, sles8.

Table 3 shows the backward and forward compatibility of 32-bit and 64-bit applications in different RHEL and sles versions:

Table 3. 32-bit and 64-bit compatibility in RHEL and sles releases

Release	32-bit	64-bit
Rhel3> RHEL4	Forward compatibility	Forward compatibility
RHEL4 <rhel3	Backward compatibility	Backward compatibility
Sles9> sles8	Forward compatibility	Na
Sles8 <sles9	Na	Na

Optimized Performance

The 2.6 kernel and power6 architecture contain features that can improve the performance of applications. Performance improvements benefit from different libraries, processor features, and compiler updates. Some performance improvements do not need to be modified, while others need to be re-compiled.Source code. Remember, recompilation for performance improvement may compromise the compatibility of binary files in some environments. This section provides examples to demonstrate the new 2.6 kernel features and power6 architecture that can improve application performance.

NUMA

Non-uniform memory access (NUMA) is introduced for Linux on power in the 2.6 kernel. This feature is further optimized in the latest versions of rhel5 and sles10. NUMA solves the problem that some processors in the system are longer than other processors because the bus locations reach a specific memory area. NUMA reduces the contention for the system shared memory bus by using more memory buses and less processors on each bus. Although this does not play a significant role in a system containing a few processors, it can improve performance when the system contains a large number of processors.

In Linux 2.6.15, numa optimization improves the performance of workloads running across large systems (with four to eight processor cores) by specifying that only the local processor can access the memory. If the processor is looking for data stored in the memory of an adjacent cell board, the Linux 2.6.16 kernel can obtain this information and move it to the local memory (faster ), then, perform the required operations in the local memory without restarting the operation.

Since the power5 and power6 architectures can be extended to 64-bit processors, most applications benefit from 2.6 kernel-level NUMA support. Applications that try to improve performance can use the user-land numa api. RHEL4 comes with the user-land numa api, and more information about how to use these APIs on the NUMA group homepage (see the references section for relevant links ).

When using Linux 2.6.16 kernel, you must make some changes based on the shared memory allocation method. If the processor is looking for data stored in the memory of an adjacent cell board, the Linux 2.6.16 kernel can obtain this information and move it to the local memory (faster ), then, perform the required operations in the local memory without restarting the operation.

Compiler Improvement

You can consider recompiling to take advantage of the new features of the latest Linux on power editor. Now, the high-performance compiler ibm xl c/C ++ version 8 can be used at the basic level RHEL4, sles9, and sles10. Ibm xl c/C ++ version 9 can be used on rhel5 and its updates, sles10 SP1 and SP2. Version 9 adds performance improvements for power6 processor-based systems.

-The qarch and-qtune options are used to optimize performance for their respective architectures. For example, to optimize the performance of power6, use-qarch = pwr6 and-qtune = pwr6. The-qtune = balanced option is also introduced. This option is used together with-qarch = pwr5 (or pwr5x) to generate binary files that can run on power5 and power6 systems, but contains scheduling improvements that can improve power6 performance. Version 9 also supports altivec vector multimedia extensions (vmx). vmx was initially provided on the IBM PowerPC 970 processor and is now integrated into the power6 product series through the-qaltivec option.

The GNU Compiler Collection contains compilers for multiple languages. Improvements have been made to versions 3.3 to 4.1, including Optimizations to its C compiler GCC specific to power6. -Mcpu = power6 and-mtune = power6 are now supported, resulting in registry usage and command scheduling parameters for the power6 architecture. In addition, it includes vmx vector extensions for IBM PowerPC 970 and IBM power6 processors to Improve the Performance of vectorized code. Although these optimization options improve performance in their respective architectures, they may compromise the binary compatibility of applications on other platforms.

On developerworksArticle"How to Use ibm xl c/C ++ advanced edition v8.0 for Linux on power: for more information about using the xl c/C ++ editor on Linux on power, see Guide for GCC users.

SMT

When migrating to a 2.6-based Linux kernel, simultaneous multi-threading (SMT) provides another performance benefit. SMT is supported on power6 and greatly improves the performance of multi-threaded applications. The power6 processor has two hardware instruction threads that can issue multiple commands in each processor cycle, thus improving performance. However, SMT may damage the performance of not many applications with threads. You can pass SMT-Enabled = off to disable SMT when the Linux kernel is started.

Other 2.6 kernel improvements

2.6 The kernel introduced the following performance improvements in RHEL4 and sles9 and further improved rhel5 and sles10:

• It can be extended to the scalability of the 64-bit SMP power6 processor.
• Support for large pages of memory-intensive applications, with 16 MB page size and a traditional 4 kb page size.
• Introduce 64 kB page size in Red Hat Enterprise Linux 5.
• Virtual Memory subsystem improvement, including reverse ing provided by systems with relatively high memory pressureAlgorithm.
• Improved block I/O and asynchronous I/O.

Migrate from RHEL4 to rhel5

Red Hat maintains a stable Abi between RHEL4 and rhel5, so you can smoothly migrate applications between the two versions. However, to ensure binary compatibility, Red Hat recommends that you link your application interfaces to the core libraries they define. The core library list includes:

• Libc, libgcc, libstdc ++, libdl, libm, libutil, libcrypt, libz, libpthread, and libncurses
• Libx11, libxext, libxt, libice, libsm, and libgl
• Libgtk, libgdk, libgdk_pixmap, libpango, libatk, libglib, libgmodule, libgthread, libgnomeprint, libgnomeprintui, libgconf, and libglade

The core library and other compatibility issues are discussed in the article "Red Hat Enterprise Linux 4 Application compatibility" (refer to the relevant link for reference ). Although this document describes the compatibility in RHEL4, the concepts and concepts are applicable to application compatibility issues in rhel5. Applications using other libraries outside the core library can still achieve compatibility, but regression testing needs to be performed further. Applications that do not retain binary compatibility include statically linking applications to other libraries, relying on kernel-level interfaces, or conflicting with POSIX standard or 64-bit power Abi definitions.

Not only does Abi maintain stability between RHEL4 and rhel5, but many other 2.6 kernel features in rhel5 are also compatible with RHEL4. This allows RHEL4 applications to use the simultaneous multi-threading (SMT) and native POSIX thread Library (nptl) features included in rhel5 to get performance improvements, instead of re-compiling their source code. These applications can also take advantage of performance improvements in the 2.6 kernel, as described above.

However, recompilation in rhel5 can improve application performance in the following two aspects:

• For systems that contain a large number of processors, recompiling the NUMA user-land API in rhel5 will improve performance (if it has not been compiled in RHEL4 ). Although in general, applications can get performance improvements from kernel-level NUMA support, further performance improvements can be achieved by re-compiling these user-land APIs. Applications with processor-intensive and memory-intensive access will get the maximum benefit, as NUMA reduces the time for the processor to access the memory area.
• When you recompile with the latest editor in rhel5, other applications may also get performance improvements. These compilers Add a flag using power6 optimization, as described earlier in this article.

When re-Compiling an application to improve performance, you must consider the risk of compromising binary compatibility. However, in most cases, migrating an application from RHEL4 to rhel5 does not require additional work.

Migrate from sles9 to sles10

Migration from sles9 to sles10 is also smooth. Although the nptl thread model is introduced in sles9 (the old linuxthreads model is no longer used), nptl is the only supported thread model in sles10, because the glibc library does not support linuxthreads. In the "thread model" section, the problem caused by changing the thread mode is described, which solves the problem of switching from one thread mode to another. Although non-thread applications with fewer common libraries can better maintain binary compatibility between sles versions, regression tests must be executed to ensure quality.

For RHEL, re-compiling the source code may be helpful for applications that will run on sles10 in some cases. For example, you can use the improved editor in sles10 to improve the application performance. SMT is also a new feature in sles10, which can improve the performance of applications containing a large number of threads.

Generally, most non-thread applications do not encounter binary compatibility issues between sles9 and sles10. However, after making major changes to the library and kernel versions, it is best to recompile the source code to achieve the best performance for the application.

Ensure compatibility between different releases

Writing an application that can be transplanted between multiple Linux distributions seems to be a difficult task, but it can be achieved by following some simple practices. The latest versions of most releases usually contain libraries and kernel versions of the same level. Most releases also use configuration and data files in similar formats.

Red Hat and Novell involved in the Linux Standard base (LSB) project of the Linux Foundation have a common goal: to develop and promote a set of open standards, to enhance compatibility between Linux releases and support running applications in the form of binary files in systems that follow these standards. In addition, LSB will help collect software vendors for porting and compiling products for Linux operating systems. The key component of LSB is the binary interface specification, which tells Linux application developers the standard way to build and configure applications. This specification specifically lists:

• General packaging and Installation Guide
• Common Shared libraries and their selection
• Configuration File
• File Location
• System commands
• Application binary interfaces (Application and platform level) for system interfaces)

The following sections detail some LSB specifications and provide some guiding principles for writing applications that can be ported across different releases.

Many Linux distributions contain the same abi and general core libraries. However, each release has a different definition of the core library. Therefore, you usually need to perform a regression test before claiming that your application is supported by a specific release.

For example, if you carefully check the glibc library contained in RHEL and sles distributions, you will find that RHEL4 contains version 2.3.4 and sles9 contains version 2.3.3. A small modification usually involves adding a repair package, rather than adding new features. RHEL4, rhel5, sles9, and sles10 both contain similar thread models. Therefore, any application linked to a common library should be able to run in these three operating environments. You can also find common libraries in other releases (such as Gentoo and Debian.

File hierarchy standard (FHS) defines the layout of files and directories on general Unix-like systems. If your application depends on other configurations and files, you may need to use FHS. The main purpose of FHS is to provide a common location for applications to find standard configuration files. You can find more information about FHS on the homepage of filesystem Hierarchy Standard. (The References section provides links ).

Binary Compatibility considerations

Although binary compatibility is defined based on abi and the processor family, there are other compatibility considerations when determining whether an application can run across multiple environments. Examples include the thread model, low-level kernel dependencies, middleware, and core library. This section discusses these considerations and describes how Linux on power handles them.

Thread mode

Since the glibc 2.3 release, the thread mode in Linux has changed, and the Linux kernel has also been upgraded from version 2.4 to version 2.6. The traditional linuxthreads model used in glibc 2.2 and kernel 2.4 has been replaced by native POSIX thread Library (nptl. Nptl is built from scratch to provide excellent performance for applications that contain a large number of threads. You can find more details about the nptl specification in the red hat article "the native POSIX thread library for Linux" (refer to the documentation for relevant links ).

Sles8 is based on the 2.4 kernel and protects the linuxthreads model. When trying to run an application containing a large number of threads on sles9 containing the nptl thread model, it will have problems. You can solve this problem in two ways:

• Make a few changes to the source code and recompile it based on the nptl-based library to obtain the performance improvement brought about by nptl. You can find more information about migrating from the linuxthreads model to the nptl-based model in the linuxdevices.com article "migrating applications to the 2.6 kernel and nptl" (refer to the relevant link for reference ).
• Set the ld_assume_kernel environment variable to provide backward compatibility for the linuxthreads model in sles9. By setting this environment variable, the connector will think that the 2.4 kernel runs the old linuxthreads model. Red Hat Developer Ulrich drepper explained ld_assume_kernel in detail (for more information, see references ). However, because glibc in sles10 has changed, applications based on the semantics of the old linuxthreads model will not work normally, because the old linuxthreads model in sles 10 has been replaced by the new nptl. This also means that the value of the ld_assume_kernel environment variable can only be set to a value greater than 2.6.4. It is best to test the nptl according to the default nptl in the updated nptl -- sles 9.

Low-level kernel dependency

When running applications in different operating environments, another consideration is the low-level kernel dependency. An example of application incompatibility is to move information from the/proc file system to the sysfs file system if the application is written with hard-coded values in one of these file systems. The/proc file system is initially a resident file system that allows the user space to access the kernel data structure containing information, such as system and device status information. This information will be moved from the/proc file system to the sysfs file system. The/proc file system still exists, but it only contains process information.

The list of devices that store Universal Serial Bus (USB) is an example of moving system information from the/proc file system to the sysfs file system. Applications originally written based on Kernel 2.4 in the system will find the device list in the/proc/bus/USB/devices directory. This information is moved to the/sys/bus/USB/devices directory after the system is migrated to the sysfs file system with the 2.6 kernel. This information movement may cause the application to not work properly. Although this is not common, you should pay attention to this kind of potential issues at the kernel level.

Middleware and application compatibility

Today, many applications are not self-contained, but dependent on middleware. Middleware is the software between two applications or between the application and the operating system. Examples of middleware include IBM DB2 Universal Database for Linux, Java Development Kit (JDK), and IBM WebSphere applications. Developers can decide the middleware version supported by their applications, but the middleware provider determines the Linux release version on which their products will run. You can find the IBM Linux middleware list on the IBM Linux software Web site. (The References section provides links ). In addition to middleware, applications may also depend on other applications attached to the release. Examples include Apache Web servers, database systems (such as MySQL and PostgreSQL), and interpretation languages (such as Perl and Python ).

As an example, we will carefully check how Java affects application developers. Java middleware packages have received much attention because the independence of the Java platform keeps Java applications high. There are not only JDK of different versions and different JDK providers, but also 32-bit and 64-bit JDK for Linux on power. RHEL4 comes with IBM 32-bit SDK for Linux v1.4.2. Rhel5 comes with IBM 32-bit SDK for Linux v1.4.2 and IBM 32-bit SDK for Linux v1.5. Sles9 SP3 comes with IBM 32-bit SDK for Linux v1.4.2, while sles10 SP2 comes with 32-bit ibm sdk v1.4.2 and IBM 32-bit and 64-bit sdks for Linux v1.5. Application developers must pay attention to these differences to prevent applications from relying only on features available in version 5.0.

Another example is that although the Apache Web Server is a non-middleware application, many applications depend on it. The latest version of Apache is 2.2, which comes with rhel5 and sles10, while Apache 2.0 comes with RHEL4 and sles9. If the features contained in the application are only available in Apache 2.2, they may be incompatible with Apache 2.0 with RHEL4 and sles9.

Core Library

Major modifications to the core library may also cause binary compatibility problems. Backward compatibility is maintained in major changes between libraries. This allows the application to compile based on the old version of the specified library to run the new version of the library. If there are major changes between the two versions of the database, the application compiled based on the latest version of the database cannot run on the old version of the database.

For example, binary files compiled on sles9 systems that contain glibc 2.3.3 can run on sles10 systems that contain glibc 2.4 because version 2.4 is backward compatible. However, the same source code compiled on sles10 won't run on sles9 because it contains the old glibc. This problem occurs only when you develop an application on the current release and want to run the application on the old release that does not provide the old version compatible library.