| Identifying the top requirements for Embedded Linux systems (Part 4) |
(conclusion)
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 . . .
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.
Related stories:
Talk back! Do you have questions or comments on this story? talkback here
(Click here for further information)
|
|
|
FUEL Database on MontaVista Linux
Whether building a mobile handset, a car navigation system, a package tracking device, or a home entertainment console, developers need capable software systems, including an operating system, development tools, and supporting libraries, to gain maximum benefit from their hardware platform and to meet aggressive time-to-market goals.
Breaking New Ground: The Evolution of Linux Clustering
With a platform comprising a complete Linux distribution, enhanced for clustering, and tailored for HPC, Penguin Computing¿s Scyld Software provides the building blocks for organizations from enterprises to workgroups to deploy, manage, and maintain Linux clusters, regardless of their size.
Data Monitoring with NightStar LX
Unlike ordinary debuggers, NightStar LX doesn¿t leave you stranded in the dark. It¿s more than just a debugger, it¿s a whole suite of integrated diagnostic tools designed for time-critical Linux applications to reduce test time, increase productivity and lower costs. You can debug, monitor, analyze and tune with minimal intrusion, so you see real execution behavior. And that¿s positively illuminating.
Virtualizing Service Provider Networks with Vyatta
This paper highlights Vyatta's unique ability to virtualize networking functions using Vyatta's secure routing software in service provider environments.
High Availability Messaging Solution Using AXIGEN, Heartbeat and DRBD
This white paper discusses a high-availability messaging solution relying on the AXIGEN Mail Server, Heartbeat and DRBD. Solution architecture and implementation, as well as benefits of using AXIGEN for this setup are all presented in detail.
Understanding the Financial Benefits of Open Source
Will open source pay off? Open source is becoming standard within enterprises, often because of cost savings. Find out how much of a financial impact it can have on your organization. Get this methodology and calculator now, compliments of JBoss.
Embedded Hardware and OS Technology Empower PC-Based Platforms
The modern embedded computer is the jack of all trades appearing in many forms.
Data Management for Real-Time Distributed Systems
This paper provides an overview of the network-centric computing model, data distribution services, and distributed data management. It then describes how the SkyBoard integration and synchronization service, coupled with an implementation of the OMG¿s Data Distribution Service (DDS) standard, can be used to create an efficient data distribution, storage, and retrieval system.
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
|
|
|
|
|
news feed