Part 4: Compatibility and Standards Issues

The term compatibility has been widely misused, OS's claiming to be 'compatible' as such — without stating to what they are compatible. So first a clarification as to how this term is being used here. Compatibility between embedded OS and desktop development systems is one aspect here, this compatibility being on the hardware and… on the software level, as well as on the administrative level. Beyond that level of compatibility there is also a conceptual compatibility, which is of importance not only for the development, but also to an even higher degree, for the evaluation of systems. The compatibility of embedded Linux to desktop development systems as understood here, is defined as the ability to move executables and concepts from the one to the other without requiring any changes. This does not mean that some changes might then be made for optimization reasons but there is no principle demand for such changes. As an example one might consider a binary that executes on the desktop and the embedded system unmodified, but in practice would be put on the embedded system in a stripped version — this is no conceptual change though.

POSIX I/II

The blessings of the POSIX standards have fallen on GNU/Linux — as much as these standards can be painful for programmers and system designers, they have the benefit of allow clean categorizations of systems, and they describe a clear profile of what is required to program and operate them. This is a major demand in industry, as evaluation of an OS is a complex and timer-consuming task, so POSIX I cleanly defining the programming paradigm and POSIX II (not so cleanly) defining the operator interface, simplify these first steps.

Network Standards

Aside from the important POSIX standards, GNU/Linux also follows many other standards, notably in the network area, where all major protocols are supported. Supported standards include the hardware standard for Ethernet Token-Ring FDDI, ATM etc., and the protocol layers TCP/IP, UDP/IP, ICMP, IGMP, RAW etc.. This standardization level allows a good judgment of a embedded Linux system at a very early project stage, and at a later stage simplifies system testing a lot.

Compatibility Issues

The demand for compatibility of embedded systems and desktop development systems touch far more than only the development portion of an embedded system. As much of the operational cost of systems lies in the administration, and a major issue, evolving even strongly now, is system security — the question of compatibility is very high ranked. The more systems become remotely accessible for operation administration, even for a full system update over the Internet, the more it becomes important to have a well-known environment to operate on. This is best achieved if the remote system behaves “as expected” from the standpoint of a desktop system for which developers and administrators have feeling for — even if many people in industry will not like this 'non-objective' criteria, it is an essential part. And looking at a modern photo-copy machine one will quickly have the impression that this is a miniaturized XTerminal that one is looking at triggering expectations on the side of the user.

Development related

During the development process for an embedded system there are a few distinct states one can mark:

• system design — one of the hardest steps in many cases.
  
• kernel adaptation (if necessary sometimes simply a recompile and test)
  
• core system development — a root-filesystem and base services.
  
• custom application development and testing

The first step is the hardest for a beginner, and having a desktop Linux system to 'play' with can enormously reduce this effort. It is very instructive to set up a root-filesystem and perform a change-root (chroot) to that directory, gathering hands-on experience for the system, systematically reducing executables, scripts, libs, etc. A highly compatible system obviously is a great advantage here. The kernel adaptation phase can be simplified, if a desktop system with the same hardware architecture is available (especially for x86 based systems this generally is the case), allowing compiling and pre-testing the kernel for your hardware. The third step — actually building the root-filesystem, is not as simple as it might sound from the first step described above. A root-filesystem needs to initialize the system correctly — a process that can not only be hard to figure out — but, also hard to debug, if the system has no direct means of talking to you (it can take a month until the first message appears on the serial console of some devices . . . ). Designing a root-filesystem requires that you gain understanding of the core boot-process. To gain this understanding a desktop system is hardly suitable, resorting to a floppy distribution (Linux-router-project or MiniRTL) can be very helpful. Where compatibility between your desktop and the target system can save the most time — is when your application runs on your desktop, if the debugging and first testing can be done on a native-platform. The biggest problems are encountered during development with cross-compiler handling and cross-debugging on targets that don't permit native debugging. Even though there are quite sophisticated tools available for this last step, a native platform to develop your application is by far the fastest and most efficient solution (although not always possible).

Operation Issues

Hardware and development expenses are a major portion for the producing side of a system. For people operating embedded systems, maintenance and operational costs are the major concern in many cases. Having an embedded system that is compatible to a GNU/Linux desktop system simplifies not only administration and error diagnostics, but can substantially reduce training expenses for operational personnel. Compatibility is also relevant for many security areas. It is hard to implement a security policy for a system with which operators have little hands-on experience. At the same time there are few documents to reference on such a security policy for proprietary systems. Being able to apply knowledge available for servers and desktop improves the situation and opens large resources on the security subject for operators of embedded systems. One further point that can be crucial is the ability to integrate the system into an existing network infrastructure. The immense flexibility of embedded Linux in this respect simplifies this task a lot.

— The end —

---

Story navigation . . .

• Part 1: The main challenges in High-end Embedded OSes
  
• Part 2: Resource Allocation
  
• Part 3: Operational Concepts
  
• Part 4: Compatibility and Standards Issues

---

Bibliography . . .

• Baraban — M. Baraban, New Mexico Institute of Mining and Technology: A Linux-based Real-Time Operating System, Thesis (1997).

• RTLinux — website, ftp site

• MiniRTL — website, ftp site

• Linux Memory Technology Devices (MTD) — website, and in the official Linux kernel

---

About the author: Nicholas McGuire's first contact with Linux dates back to Linux kernel version 0.99.112, at a time when many rumors and myths were circulating about the fledgling open source operating system. McGuire first came into contact with RTLinux at RTL version 0.5, in the course of developing a DSP system replacement for magnetic bearing control, at the Institute for Material Science of the University of Vienna, Austria. McGuire began developing MiniRTL while RTLinux was at version 1.1, and has been engaged in RTLinux and MiniRTL based development work ever since.

---

---

 
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.