Migrating to Linux: How and Why
Open Source Engineering moves centre stage
Linux is firmly established in the embedded market, but migrating existing source code to the operating system is a considerable undertaking.
Hans Juergen Rauscher explores the different steps necessary to migrate, the technical requirements and possible pitfalls, and the differences between buying an established Linux implementation and developing and maintaining one internally.
Linux has gained a firm position in the embedded market. This raises the question of whether it is worth developing new products with Linux and replacing an existing operating system with Linux. There is effort and risk in any migration of an operating system, and the technical difficulties and analysis and planning for migration to embedded Linux require consideration and time.
|A – X of Linux|
|B||Broadcom and LiMo|
|C||Carrier Grade Linux|
|F||Free software embedded|
|H||How to migrate|
|J||Jumping on board|
|N||Nokia does battle|
|O||Open Source engineering|
|R||RTOS versus Linux|
|U||UK radio mapping|
|W||2 Watt green PC|
|X||Xilinx adds Linux|
Spelling out GNU and Linux stories
The reasons for migrating an operating system differ radically from company to company and even from one product to another. It can offer new functionalities and technologies when the performance of the current hardware and operating system has become inadequate. In addition to the end-of-life for hardware and software components making migration necessary, it is quite common to migrate to a new system to save costs.
Linux has established itself not only in corporate information technology but in the embedded market. This is mostly a result of the scale and availability of reusable source code, the broad support of different types of hardware, the large number of developers who use it, and an anticipated cost reduction. Linux is highly flexible and offers complete control over development tools and the operating system and associated packages.
Linux currently offers an operating system platform technology that is also suitable for embedded systems. Hard real-time and certification, which are vital in the industrial sector, are still under development.
Applicatio n software usually represents added value to an existing product and represents a competitive advantage. It is usually the first choice for project managers looking to migrate.
The necessary middleware - the software that makes running the application possible - is often enhanced with desirable functions, which makes migration even more attractive. However, many middleware implementations use a lot of operating system-specific functions, and this makes migration less sensible than a new implementation.
How to Migrate
If Linux is chosen as the operating system for the migration, the next step is to outline an efficient course of action. First, determine the migration goal and assess the risk management. In principle, there are three feasible methods of converting applications to Linux. For the first approach, the majority of the effort is spent on application redesign and provides an opportunity for maximizing the value of Linux. Existing source code is suitable for porting if the API (e.g., UNIX or POSIX) and the internal structure of the application are similar to Linux. As an example, the migration model used by the device software firm Wind River is shown in Figure 1 below.
Figure 1: The Wind River Professional Services migration methodology (click to expand)
If the source code is too strongly interwoven into the current operating system’s API, an API intermediate (or shim) layer should be inserted to communicate between the current operating system’s API and the Linux API. If not, the application can be bundled with the current operating system straightaway and layered onto Linux (see Figure 2).
Figure 2: Applications may be redesigned, ported or reused, even with a legacy OS (click to expand)
This approach requires a hardware abstraction layer, or HAL, for the legacy OS, which may be hard to achieve if the OS does not use a HAL or if it is not documented. As an alternative, virtualisation technologies can be used to encapsulate the bundled OS and application. Ideally this virtualisation is also supported by the target CPU to keep performance on an acceptable level.
There are also several Linux-specific issues that should be considered when migrating. The current real-time operating system tasks are grouped as Linux threads under a Linux process, so the separation in user space and kernel space has to be taken into account.
Depending on the required response time of the application and the CPU performance, the Linux kernel may be able to satisfy these without modification (with a response time of tens of milliseconds) or may require additional functionality such as the PREEMPT_RT kernel patches (with a response time of tens of microseconds).
If the application requires deterministic, 100% guaranteed response times in the range of single-digit microseconds, Linux may not be able to satisfy this by itself. Instead, a real-time scheduling mechanism, such as Wind River Real-Time Core for Linux, can be added. This controls the CPU and provides computing time to Linux only if there is no real-time thread or interrupt service routine that requires the CPU time.
The transition of a frequently used flat memory model with physical addresses to one with virtual addresses and pages protected by a memory management unit will also make some code changes necessary. The interprocess communication and synchronisation should be retained, provided there are no compatibility issues.
Linux has a strong user- and file-structure, so customization is likely to be required here as well. One way to deal with this is to write an application startup wrapper that sets up the environment and then starts the migrated application as a child process. This means fine-tuning of the RTOS task priorities is needed for the Linux process/thread model.
It also doesn’t make sense to migrate device drivers, so if this is needed, a new implementation should be planned.
The increased demand for RAM and flash memory for Linux must also be considered when designing the hardware. A typical Linux kernel is around 1 to 2 megabytes, which results in a typical 8MB RAM requirement for a Linux system. For easier testing and debugging the code of a JTAG interface, serial and Ethernet interfaces should also be available, at least on the development board.
Booting Linux differs distinctly from real-time operating systems as it needs a boot loader and access to a mountable root file system containing all the necessary binary packages. This can reside on a flash, a directly attached disk or an NFS file server in the network.
In principle there are four types of Linux:
- Building Linux yourself (also called “roll your own,” abbreviated as RYO) is the most original type of Linux. It provides total control but comes with the full responsibility for maintaining and supporting it. In addition to the substantial effort of maintaining it, there is high project risk; these do not contribute to the features or value of the end product.
- Free Linux distributions such as Ubuntu, Fedora, OpenSUSE or Debian are frequently unsuitable for embedded projects due to their primary focus on the x86 CPU architecture and servers or desktop PCs.
- Linux versions offered by hardware manufacturers are usually not up-to-date and are rarely maintained or supported long-term. They also lack the tight integration with development tools beyond the compiler and so are often inadequate even though they offer increased support for target hardware platforms.
- Commercial Linux, such as Wind River Linux, offers the benefits of Linux with openness, source code and wide support, without the added development and debugging effort or limitations associated with RYO or hardware-vendor distributions.
With careful planning and consideration of the issues involved, the migration to embedded Linux can have considerable success.
The application environment and the ongoing support requirements mean, in practice, that commercially available embedded Linux is often superior to the other variants such as self-built Linux. This allows the developer to focus on the application and the added value of the end device and minimises the short and long-term risks of the migration.
Hans Juergen Rauscher, system architect, networking, Central Europe, for Wind River, Germany, consults key telecom accounts about networking technologies and Linux.