RTOS, secure virtualization technology for real-time systems, DO-178B and hypervisor for the most demanding embedded operating system applications...

The Technology Behind LynxOS v4.0's Linux ABI Compatibility

This article was originally published by LinuxDevices.com, June 4, 2002, at http://www.linuxdevices.com/articles/AT8943314364.html. With the kind permission of LinuxDevices.com, it is being reproduced here.

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
Figure 1: LynxOS ABI Environment
Figure 1: LynxOS ABI Environment

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.

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

LynxOS white papers
Partitioning Operating Systems Versus Process-based Operating Systems
Real-time Secure Operating System
Safety-Critical Software
The Technology Behind LynxOS v4.0's Linux ABI Compatibility
Using the Microprocessor MMU for Software Protection in Real-Time Systems
Providing Open Architecture High Availability Solutions (PDF, 815kB)
Patented Threaded I/O Handling
An Empirical Evaluation of OS Endsystem Support for Real-time CORBA Object Request Brokers (at Washington University)
POSIX in Real-Time (at embedded.com)

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 availbility 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

Figure 2: LynxOS ABI
Figure 1: LynxOS ABI Environment

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.

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.


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.


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.


Arun SubbaraoAbout the author:

Arun Subbarao is Vice President of Engineering at LynuxWorks and is responsible for the LynxOS 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.

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.

A LynuxWorks embedded OS is featured in this embedded system application:
Who else uses a LynuxWorks embedded operating system?
Security white papers
Separation Kernels Enable Rapid Development of Trustworthy Systems
By using separation kernel technology and a security abstraction design approach, military system developers can use off-the-shelf components and tools to rapidly build and maintain high security systems. (March 2014)
Coming Together of Safety and (Cyber) Security Changes Demands in RTOS Market
Separation kernels and secure hypervisors will be evermore in demand as safety and certification will be required in more and more applications. Governments are already working on infrastructures deploying this type of technology. (October 2012)
Building in RTOS Support for Safety- & Security-Critical Systems
LynuxWorks explains the differences between safety-critical and security-critical applications and how to meet their demanding requirements with the LynxOS-178 RTOS and the LynxSecure hypervisor. (EE Times Design, August 2011)
Enhancing Application Performance on Multicore Systems
Tips on optimizing a multicore real-time system, including virtualization, avoiding synchronization and concurrency while maximizing application parallelism. (Military Embedded Systems, February 2011)
Hardware Virtualization puts a new spin on Secure Systems
Real-time determinism and military security don't have to be separate realities. A combination of a secure separation kernel and an embedded hypervisor enables whole new levels of system security. (COTS Journal, October 2010)
Using a Separation Kernel to add Military-Grade Security to Legacy Systems
A challenge for the software designer is how to integrate modern military-grade software programs into legacy software designed long before security standards were predominant in system requirements. (VME Critical Systems, Summer 2010)
Virtualization: Keeping Embedded Software safe and Secure in an Unsafe World
A new, secure methodology is needed to separate systems of different security levels which run on shared resources—without compromising the performance of legacy systems. (EE Times, June 2010)
Secure Virtualization Combines Traditional Desktop OSs and Embedded RTOSes in Military Embedded Systems
Advances in software and hardware technologies now make it feasible to use both embedded and desktop operating systems in a secure military system. (Military Embedded Systems, May 2010)
DO-178B Provides Certification Safety net
Developers of commercial avionics software must demonstrate compliance with DO-178 guidelines. The FAA has issued additional guidance for so-called DO-178B Reusable Software Components (RSCs as defined in AC20-148), which allow for reuse of certifications. (COTS Journal, November 2009)
Designing Safety-critical Avionics Software Using open Standards
Safety-critical avionics systems have continually grown more complex and software-intensive. Regulatory authorities and avionics manufacturers have responded with guidance such as DO-178B and RSC to ensure that software performs safely, with controlled development cost. (Boards and Solutions, September 2009)
Two Different Realms: RTOS Support for Safety-critical vs. Security-critical Systems
Safety- and security-critical system functions are evolving simultaneously, with different yet similar requirements. Modern RTOSes are stepping up to meet these needs. (VME and Critical Systems, June 2009)
Virtualization Makes Better use of Open-source OSes and apps
With the introduction of the embedded hypervisor, embedded systems can avoid certain performance or licensing issues inherent to open-source OSes and applications. (EE Times, March 23, 2009)
Secure Virtualization Technology can Extend the life of Legacy Systems
By combining the concept of virtualization and security, one can consolidate multiple legacy systems running on heterogeneous operating systems onto a single host system with high-assurance security. (Military Embedded Systems, January/February 2009)
Virtual Machines: Intel's CPU Extensions Transform Virtualization
Virtualization has traditionally presented its share of design challenges in information-assurance-based systems. But now, Intel's VT-x and VT-d CPU extensions are changing the game and showing potential to become the de facto path to virtualization. (Military Embedded Systems, January 2009)
Separation Kernel for a Secure Real-time Operating System
The technical foundation adopted for the so-called MILS architecture is a separation kernel like LynxSecure, which permits multiple functions to be realised on a common set of physical resources without unwanted mutual interference. (Boards and Solutions Magazine, February 2008)
Advances in Virtualization aid Information Assurance
Advances in the newest Intel® processors are making virtualization much easier to implement in security applications than ever before. (Embedded Computing Design, January 2008)
Protecting our most Vital Systems
Some significant defence programmes are already committed to a new approach to high-threat, high-asset-value systems. Rance DeLong explains MILS. (Components in Electronics, April 2007)
Perspectives: Security and the Separation Kernel
Today's avionics systems are designed to support more than one application, using a partitioned operating system and memory management units to ensure applications have adequate separation. (Avionics Magazine, April 2007)
MILS: An Architecture for Security, Safety, and Real Time
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Technology Magazine, November 2006)
Partitioning Operating Systems Versus Process-based Operating Systems
Partitioning operating systems are the latest buzz, while processes, by contrast, have been around for over 30 years. Both provide memory protection, however, the intent behind them is very different.
DO-178B and the Common Criteria: Future Security Levels
Although there are similarities between the airborne safety-critical requirements in RTCA/DO-178B and the Common Criteria, ISO 14508, compliance with the higher levels of security in the Common Criteria demands meeting additional security requirements. (COTS Journal, April 2006)
Reusing Safety-Critical Software Components
Safety-critical systems often operate together as a single "system-of-systems," making it important that they meet the most stringent and rigorous requirements for safety-criticality. The failure of one module in a system could create other failures or vulnerabilities, or worse yet, failure of the system as a whole. (COTS Journal, August 2005)
Using the Microprocessor MMU for Software Protection in Real-Time Systems
With minimal impact to overall system performance, user tasks and the kernel can be protected from accidental corruption by using multiple protected address spaces.
Improving code Migration and Reuse
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Computing Design, August 2006)
FCS Program Rolls Forward in Formation
A wireless data network, with advanced communications and technologies, links soldiers with 18 new, lightweight manned and unmanned ground vehicles, unmanned aircraft, sensors and weapons—and it's all in one program. (COTS Journal, June 2005)
Secure Operating Systems for Deeply Embedded Devices
As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address. (RTC Magazine, September 2004)
LynxSecure Separation Kernel and Embedded Hypervisor LynxOS-SE Embedded RTOS Luminosity Eclipse-based IDE
LynxOS Embedded RTOS RTOS: LynxOS-178 for software certification


SpyKer Embedded-System Trace Tool

Industry Solutions


Industry Standards

Embedded Systems Technology

RTOS Training for Embedded Systems

Training at LynuxWorks

LynuxWorks Support

Embedded Systems

LynxOS RTOS Support

Embedded System Consulting

Contact Us

About LynuxWorks

Press Room

Newsletter and Announcements



Site Map

Board Support Packages (BSPs)

BSP Device Drivers

BSP Targets by Operating System

BSP Targets by Form Factor

Third-party I/O Devices and Hardware

SynergyWorks: LynuxWorks partners

What is SynergyWorks?

Third-party add-ons for LynuxWorks operating systems

Copyright © LynuxWorks™, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of LynuxWorks is prohibited.