The Embedded Linux Consortium Platform Specification [LWN.net]

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.

to post comments

Embedded fragmentation? A worry??

Posted Feb 20, 2003 15:51 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]

While it's certainly nice to see signs of cohesion in any segment of the embedded world, I had to laugh at the comment

Embedded Linux, in particular, has been subject to the sort of fragmentation that creates worry among technology pundits and corporate managers

In my time in the embedded world (hint: I subscribed to Embedded Systems Programming from issue 1, when you had to pay for it) the words embedded and fragmented have always been synonymous.

Let's look at their 2002 buyer's guide: the heading `Real-Time Operating Systems / Kernels / Executives' runs from pages 28 to 51, inclusive, and contains only two (admittedly, full-page) ads. I don't feel like counting, but at a conservative six listings per double-page spread, you get to choose from some 66 products that want you to think you can run your app on them + bare metal. And that leaves out the (tens of?) thousands of roll-your-own practitioners. Fragmented? Can you say ``Smashed to flinders''?

It's great to see some standardization coming in---the low cost of high performance these days will allow us to throw plenty of x86-compatibles into the fray without a qualm, simply because you can boot it on day two, and be productive on day three. But there's a reason for the seemingly-insane variety of embedded offerings: the same variety in products, vastly larger than Compaq or Dell could ever dream of. I guarantee my USD 25 toaster has a microprocessor, but it ain't an x86. In the majority of embedded products, they're planning to sell so many widgets that saving ten cents each trumps a couple weeks of an engineer's time. The only people worried by embedded fragmentation are those outside the industry.

I predict in five years (I'm being real cautious here) we'll have dozens of little Linuces, all different, all meeting one of the then-current standards.

Best wishes,
Max Hyre

P.S.: I fear we may not have ESP around much longer, at least in print form; my latest issue was forty pages, down from around ninety mid-last-year, and well over a hundred in years past.

The Embedded Linux Consortium Platform Specification

Posted Feb 21, 2003 2:18 UTC (Fri) by GreyWizard (guest, #1026) [Link]

NPTL will be in the next RedHat release, most likely in a patched 2.4 kernel.

The Embedded Linux Consortium Platform Specification

Posted Feb 21, 2003 11:13 UTC (Fri) by ajosey (guest, #1938) [Link]

The statement about the POSIX realtime standards being in flux
does not hold. The realtime standards, 1003.1b-1993, 1003.1c-1995,
1003.1d-1999, 1003.1j-2000 and 1003.1q-2000 are all final approved
standards, stable, and rolled in as options to IEEE Std 1003.1-2001
(POSIX) and the the Single UNIX Specification Version 3 Realtime
Option groups. (IEEE Std 1003.1-2001 is approved as international
standard ISO/IEC 9945:2002 parts 1 thru 4)

IEEE has realtime profiling effort underway to revise IEEE Std
1003.13-1998 to adapt to IEEE Std 1003.1-2001, see http://www.pasc.org/sswg-rt/ . This is open to all for participation,
and is taking a similar approach to the ELC, in so much as both
it and the ELC specification have drawn from the subprofiling
recommendations (see
http://www.opengroup.org/onlinepubs/007904975/xrat/subprofiles.html )