Abstract

LynxOS v4.0, the newest release of the POSIX-conformant hard real-time operating system (RTOS), has support for Linux ABI compatibility — where Linux application binaries can run unchanged in the LynxOS environment without necessitating source code recompilation. This white paper examines the issues surrounding ABI compatibility in general and describes the architecture of the Linux ABI compatibility layer on LynxOS v4.0.

What is ABI?

Application Binary Interface or ABI refers to the run-time interfaces between an application program and the OS environment where it is executing. The components of the OS environment that form the ABI for a particular OS are:

• Object file format
  
• Application Programming Interface (API) calls
  
• Dynamically linked libraries
  
• Run-time linking and loading

The OS environment usually provides a single object file format by default for all applications within this environment. The various object file formats that are used within the OS environment are A.OUT, COFF, XCOFF and ELF. The OS environment also consists of a set of well-defined API calls defined within the OS or in a set of dynamically linked libraries. Application programs typically invoke these API calls to access OS services through the dynamically linked libraries. The run-time linking and loading support in the OS facilitates program execution by resolving all unresolved API calls in the application to the dynamically linked libraries at run-time.

The LynxOS ABI environment is shown in Figure 1.

Figure 1: LynuxOS ABI Environment

ABI Compatibility and its usefulness

ABI compatibility refers to the extent of run-time support provided by two different OS environments to support execution of application programs. The extent of ABI compatibility that exists between two OS environments dictates whether application programs that are created under one environment will run unchanged in the other environment. ABI compatibility if supported between two OS environments obviates the need to re-compile and re-link application programs built in one environment, in order to run in a different environment.

This has several benefits since it helps to surmount difficult legacy issues like unavailability of source code, unavailability of the technical expertise familiar with the application and unavailability of current resources.

ABI compatibility can extend to application programs executing in the following environments:

• Multiple releases of an Operating System on a particular hardware platform — The issues associated with ABI compatibility in this environment usually involve the dynamic system libraries and the exported API calls that are used by application programs. Since the file format between two releases of an OS changes infrequently, the extent of ABI compatibility is directly related to the changes in API calls between the two OS releases. As long as the API calls do not change in the OS or libraries, applications built for an earlier release can run unchanged in the new release.

• Two completely different Operating Systems — ABI compatibility between two different Operating Systems is more complex. Ideally the two different Operating Systems ideally need to have the same object file format to ensure ABI compatibility. This gets to be harder between two disparate operating systems like Windows and Unix. Secondly the two Operating Systems need to have a compatible set of API calls. The greater the level of API compatibility between the two OS environments, the easier it is to achieve ABI compatibility between them.

• Different hardware platforms — ABI compatibility between two different hardware platforms creates several additional problems that make it extremely complex. Besides the common object file format and API compatibility issues, the underlying processor architecture needs to be emulated through a virtual machine.

LynxOS-Linux ABI layer: The technology

The LynxOS-Linux ABI compatibility layer provides Linux ABI compatibility on LynxOS and provides an execution environment for Linux application programs to run unchanged in a true hard real-time environment.

The Linux ABI compatibility support in LynxOS v4.0 creates an OS execution environment for Linux applications that is similar to the one provided by the Linux operating system. The key components that are provided for Linux ABI compatibility in LynxOS are described in the next sections.

Compatible object file format

LynxOS v4.0 uses the ELF (Executable and Linking Format) as its default object file format. This ensures file format compatibility with Linux, which also uses the ELF file format as its default and provides the basic platform for ABI compatibility.

Dynamic linking

All well-behaved Linux applications are linked dynamically by default. (The Linux Standards Base / LSB specification defines a Linux application as LSB-conforming only if it is dynamically linked.) The Linux OS environment by default builds an application with dynamically linked library dependencies that are subsequently resolved by the run-time linker and loader during program execution. The resolution of these shared library dependencies in Linux is done by the run-time linker and loader (ld-linux.so), which loads all the required dynamic libraries used by the application into memory, and resolves all unresolved references with these libraries. The dynamic linking support in LynxOS v4.0 follows the widely used Unix System V (SVR4) ABI for dynamic linking of applications. Dynamically linked applications identify the run-time linker and loader (ld.so) in the application's file format at build-time. During program execution, ld.so loads all needed shared libraries into memory and resolves run-time dependencies.

The similarity of the dynamic linking support between Linux and LynxOS forms another key component of Linux ABI compatibility on LynxOS.

API compatibility

One of the most significant components needed to ensure Linux ABI compatibility on LynxOS is the availability of a common API. Most Linux applications use a significant set of API calls that are provided by the Linux kernel. (Linux kernel v2.4.x provides over 200 system call APIs.) The ability of the LynxOS execution environment to duplicate the behavior of each of these system calls invoked by a Linux application is essential to ensuring its successful execution.

LynxOS being a UNIX/POSIX conforming RTOS has over 150 system calls that are similar with the Linux system call API. However to ensure that these system calls behavior is identical to Linux, changes were made in the following areas:

• Some system calls that were not present in the LynxOS API were added to provide a higher level of compatibility with Linux (e.g.: fchdir, setresuid, setresgid, wait4).
  
• Signal numbers in LynxOS were changed to ensure a match with the Linux signal numbering scheme.
  
• The constants used for IOCTL calls in LynxOS were changed to match Linux.
  
• The error numbers that are returned by system calls (errno) in LynxOS were changed to match Linux.

The resultant LynxOS system call API has an extremely high level of compatibility with the Linux system call API with very minimal overhead for the LynxOS kernel. This convergence between the two Operating System APIs is the critical component to ensuring ABI compatibility between the two.

Dynamically linked libraries

Dynamically linked libraries in Linux provide additional sets of API functions that applications can dynamically link to, and the system call binding between Linux applications and the Linux kernel. The availability of Linux dynamic libraries in the LynxOS execution environment is essential for Linux ABI compatibility support on LynxOS v4.0.

LynxOS v4.0 uses a modified version of the Linux GLIBC dynamic library to resolve application calls at run-time. This modified GLIBC library provides the translation between Linux and LynxOS system calls. Application calls to GLIBC functions that are independent of system calls remain unchanged and are unaffected by the underlying LynxOS execution environment. However, application calls to Linux system calls are intercepted at the system call binding code in the modified GLIBC. Glue code was added in GLIBC to either call the LynxOS system call directly or make any modifications before the LynxOS system call invocation to ensure that the Linux system call behavior is achieved. Using this mechanism, a broad spectrum of Linux system calls is supported including Pthread interfaces, Asynchronous IO, Networking and other POSIX interfaces.

Further, any Linux dynamic library that does not have any system dependencies can be copied from Linux and used unchanged on LynxOS. The LynxOS run-time linker and loader recognizes the dynamic library dependency through the application ELF headers and proceeds to resolve application calls to these libraries (e.g.: libz.so.1, libjpeg.so.62 etc).

However, if an application uses a system call that is unsupported, it fails immediately and consistently since the corresponding system call binding does not exist in GLIBC.

Overall architecture and limitations

Thus the overall architecture of the LynxOS-Linux application compatibility layer, as shown in Figure 2, combines the described set of components to provide an OS execution environment capable of executing an extensive set of Linux applications.

Since the ABI compatibility support is tied to the system API compatibility and dynamic library support, LynxOS-Linux ABI compatibility is currently dependent on a Linux kernel and GLIBC pair. LynxOS v4.0 supports applications based on Linux kernel v2.4.x and GLIBC v2.2.2/v2.2.4.

The current implementation does not provide support for statically linked Linux applications, application that make direct system calls and applications that use a feature that is not supported in LynxOS (e.g.: /proc file system). However this is a subset of the total available Linux applications.

Figure 2: LynuxOS Linux ABI

Compatibility Testing

The compatibility testing of the Linux ABI compatibility layer was done using a combination of automated and manual testing.

The automated testing of the LynxOS ABI compatibility layer uses the Bluecat Linux automated test suite (ATS) that contains over 5000 tests of POSIX 1a, 1b and other Linux system call interfaces. These automated test suites were built in a Linux kernel v2.4.x/GLIBC v2.2.2 environment and run on the Bluecat Linux product for baseline qualification. These same test binaries were then executed unchanged on the LynxOS v4.0 execution environment and test results were compared to ensure no difference in results.

The manual testing involved testing advanced Linux applications with several system and application-supplied dynamic libraries. Several advanced applications were successfully tested like the Opera browser, ACE-ORB, Gnome and KDE.

Performance

The performance considerations of the Linux ABI compatibility layer focus on two main areas:

• Performance impact for LynxOS native applications
• Performance of Linux applications on LynxOS

The architecture of the Linux ABI compatibility layer on LynxOS is largely independent from the LynxOS native functionality. The kernel modifications that have been introduced to achieve better API compatibility mainly affect signal numbers, errno values and IOCTL values. These do not introduce any additional overhead and hence the performance of LynxOS native applications are completely unaffected by the ABI compatibility layer.

The performance of Linux applications on LynxOS is mainly dependent on the additional glue code that is introduced in the GLIBC library. However the glue code in most cases is very minimal, merely translating system call parameters and bit fields before invoking LynxOS system calls and translating it back to the application after the system call returns. This introduces very minimal overhead and the overall performance impact on the application is negligible.

Benefits

The Linux ABI compatibility layer on LynxOS v4.0 provides several benefits to customers:

• This capability provides support for Linux applications to run in a true hard real-time environment along with LynxOS native applications.

• The ability to execute a Linux application binary without recompilation surmounts the issue of unavailability of application source code. Proprietary applications can run without the need for any additional porting effort.

• In several instances, the technical resources that originally wrote the application may not be available to the company or allocated to different projects. In this case, the capability of avoiding source code recompilation could save the organization significant costs.

Conclusion

The Linux ABI compatibility layer on LynxOS v4.0 creates a unique execution environment where Linux applications can run unchanged in a true hard real-time environment. It provides the ability to leverage innumerable open source as well as proprietary applications to better meet time-to-market needs in the creation of products in the embedded marketplace.

---

About the author: Arun Subbarao is the Director of Software Engineering for LynuxWorks and is responsible for the LynxOS 4.0 product development. Arun has more than 10 years experience in the OS and embedded industry working on Unix, Linux, and RTOS development. His interests include Operating Systems, Networking, and High Availability.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.