| Introduction to the ELC's new Embedded Linux platform spec |
Kevin Dankwardt (Jan. 6, 2003)
The Embedded Linux Consortium (ELC) has just released the ELC Platform Specification (ELCPS). As an active member of the Embedded Linux Consortium's Platform Specification Working Group, I invite all interested to carefully study the specification.
This article serves as a brief explanation of the process that led to the development of the specification and a cursory description of its contents. Information about how to obtain the specification can be obtained at the ELC's website.
[Editor's note: an announcement about the release of the ELCPS is located here, and you can download it here.]
Specification Requirements and Rationale
The ELCPS was designed to be an API specification, thus supporting source level portability of applications to different implementations. This design ensures a specification that provides developers of applications and middleware assurance that their products can be recompiled for a large variety of potential embedded Linux targets. This means that, say, a developer of a messaging package, that requires only functionality contained within the Specification, should be able to recompile their package for any compliant implementation (one that relies only upon APIs given in the Specification). Further, the API level specification ensures usefulness of the Specification for all potential architectures.
The specification of an API also gives embedded Linux implementers guidance in the functionality that should be provided. In order to not unduly burden implementers, and creators of resource limited devices, The Standard provides for three successively larger Environments.
Based on existing standards
The ELCPS takes much from existing standards. These are the Linux Standards Base, POSIX, and Standard Unix Specification v3 standards. This tack was taken for several reasons: to more quickly produce a standard; to ensure that existing Linux practice is recognized; and to incorporate sound standards methods. The ELCPS specification does not intentionally differ from the standards it is based upon except for a few clearly needed additions such as the naming of macros with an "ELC" prefix, a distinction of multiple address support, and the _SC_ELCPS_ENVIRONMENT constant which is used with the sysconf() system call.
The ELC prefix is needed to ensure that the ELCPS macro names differ from existing names. The multiple address space distinction was devised as a means to allow a fairly rich environment yet still allow for implementations, such as uCLinux, on MMU-less devices to comply. In systems without multiple address spaces, the vfork() function may exist, but not fork(). With vfork() an application may create multiple processes, but, they will share an address space. Thus, the requirement for multiple processes but not multiple address spaces was shown to be a valuable capability in practice.
The _SC_ELCPS_ENVIRONMENT constant is the only feature that the ELCPS invented. This mechanism was added after lengthy discussion about how to allow an application to dynamically query what ELCPS environment is supported.
Additional considerations and features
The ELCPS contains no real-time related specifications. This choice was made for several reasons including no standard practice of providing real-time functionality for Linux currently exists.
The ELCPS does not require any particular origin of compliant systems. This means, for example, that a system need not contain a Linux kernel. This choice was made because the goal is to produce a platform in which developers of applications and middleware will find widely available. A system that complies with the ELCPS, that happens to originate independently from Linux, will still provide this increase in the availability of a standard platform implementation that is sought. This is the same choice, incidentally, that the Linux Standards Base has made.
Standardization on a threading model provided a difficult challenge. The predominant threading implementation in use on Linux, the one provided with the GNU C Library, lacks many features of the POSIX standard. In order to accommodate the use in practice of the GNU implementation as well as allow for the use of a POSIX standard implementation, the ELCPS allows an implementation to supply either, or both. If an implementation provides both, the interaction between the two must be described. One should note that a POSIX compliant threading implementation for Linux should shortly be available, as there are at least two different projects nearing completion right now (IBM's NGPT and Ulrich Drepper's NPTL).
The ELCPS
The ELCPS is defined in terms of forty-four function groups. These groups, for the most part, correspond to groupings in LSB and/or POSIX specifications. The ELCPS specifies three system environments: Minimal, Intermediate, and Full. These environments are specified in terms of which function groups they contain. The Intermediate environment is a proper super-set of the Minimal Environment, and the Full Environment is a proper super-set of the Intermediate Environment.
The most innovative feature of the Minimal Environment is that while multiple processes may be present, applications may not depend upon multiple address spaces. This accommodates, for example, uCLinux.
The Intermediate System Environment is used when multiple processes with protected address spaces are required, but, multiple user accounts and socket operations are not.
The Full System Environment is quite rich in functionality. It requires the full functionality required by sophisticated applications. It also, requires, for example, functionality provided by the GNU C Library but not currently by uCLibC. In my opinion, though, a Full System Environment may fit in a couple MB of Flash, for example, and thus is justified within a specification targeting embedded systems.
A quick count of the required functional groups and functions that are required for each environment shows that the Minimal SE requires 371 functions coming from 7 groups; the Intermediate SE requires 667 functions coming from 27 groups; and the Full SE requires 1121 functions coming from 44 groups. This list includes the POSIX and LSB items as required. In addition, implementations must provide a header file, "elcstd.h", that contains the ELCPS symbolic constants. These constants allow for, among a few other things, the testing of what function groups are present. These are for use at compile time.
Summary
The ELCPS provides a non-controversial and meaningful standard that should be valuable to embedded Linux system implementers and application developers alike.
Credits: thanks to Bao Ha, Murry Shohat, Dongjun Shin, Mark Brown, Joe deBlaquiere, and Thiru Govindan for their comments and contributions to this article
 About the author: Kevin Dankwardt is founder and President of K Computing, a training and consulting firm. He has spent most of the last 9 years designing, developing, and delivering technical training for such subjects as Unix system programming, Linux device drivers, real-time programming, and parallel-programming for various organizations world-wide. He received his Ph.D. in Computer Science, in 1988.
Relates stories:
Talk back! Do you have comments or questions on this article? 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