News Archive (1999-2012) | 2013-current at LinuxGizmos | Current Tech News Portal |    About   

Article: Introduction to the ELC’s new Embedded Linux platform spec

Jan 6, 2003 — by LinuxDevices Staff — from the LinuxDevices Archive — 4 views

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:

 
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.

Related Posts:



Comments are closed.