The Embedded Linux Consortium Platform Specification

The Embedded Linux Consortium has announced the launch of the ELC Platform Specification (ELCPS). The ELCPS was developed with input from numerous companies including IBM, LynuxWorks, Panasonic, Samsung, MontaVista, K Computing, Red Hat, WiPro, Hacom, and FSM Labs; its purpose is to encourage interoperability across embedded Linux systems. Those wanting the details can grab a copy of the specification in PDF format; for everybody else, here is a quick summary of what the ELCPS is trying to do.

The ELCPS is heavily influenced by the Linux Standard Base, POSIX, and the Single Unix Specification. However, it restricts itself to the programming environment (and, in particular, to which functions should be available) and is not concerned with the user experience side of things. It is assumed that the user of an embedded system will not be worried about which shells are available.

Of course, not all embedded systems are the same; the capabilities needed by a web-enabled phone handset or point of sale system will be different from, say, an elevator controller. So the ELCPS defines three levels of environment, each of which has different requirements.

• The minimal system environment is the bottom end; systems running in this mode may not deal directly with users, and may not even need a filesystem. ELCPS-compliant systems at this level should provide the basic C environment, signals, basic locking, and threads - but they do not necessarily have to be able to run more than one process.

• The intermediate system environment adds several things, including filesystem support, asynchronous I/O, dynamic libraries, multiple processes, inter-process communication, wide character support, and more.

• The full system environment is "essentially equivalent to a LSB 1.2 system," except that there is still no specification of which programs should be available. At this level, the environment should provide full floating-point math support, job control, networking, basic shell functions, system logging, password functions, and so on.

There are a couple of interesting omissions from the first version of the ELCPS. One is in the area of real-time programming. According to the specification, there is no clear standard for real-time programming in the Linux world. The LSB does not specify real-time functionality, and the POSIX real-time standards are still in flux. The specification makes no mention of the fact that serious real-time Linux programming tends to be done by way of RTLinux or RTAI, neither of which is standard in any way, but that situation has to have discouraged attempts to standardize real-time Linux functionality as well.

The specification also had to punt on thread support, since real POSIX threads implementations for Linux are still hard to come by. That situation should be rectified when the 2.6 kernel, with its greatly improved threading support, becomes available.

The Embedded Linux Consortium will eventually set up a certification program for ELCPS compliance.

The ELCPS is another sign that the embedded Linux community (and Linux in general) is growing up. Embedded Linux, in particular, has been subject to the sort of fragmentation that creates worry among technology pundits and corporate managers; the ELCPS should help those people to worry a bit less. By using embedded Linux, manufacturers are already able to free themselves from proprietary platforms and royalty payments. The ELCPS should make these manufacturers more confident that they will not find themselves locked into a single vendor. And that, of course, should be good for the Embedded Linux market as a whole.

---

(Log in to post comments)