Embedded Systems -> Posix eases route to embedded Linux

The goal of EL/IX is, first and foremost, to standardize the APIs available in desktop Linux today in such a way that embedded system developers have a clear and consistent idea of what functionality they can expect for a given embedded target:

• Support for developing embedded applications using the Linux desktop environment as both a host and development platform.
• A way to scale that functionality according to the requirements of the embedded target.
• The freedom to use any kernel (Linux or otherwise) that implements the interfaces of EL/IX that the application requires;
• The ability to easily port to any hardware that runs any kernel that supports the subsets of EL/IX they require.

Moreover, the first version of EL/IX adheres to these additional requirements:

• The elements must already be implemented in standard Linux distributions (i.e., don't define what doesn't exist).
• It's possible to demonstrate real real-time performance when running on a real real-time OS (prove it works beyond Linux).
• It is based on Posix where possible (bui ld on accepted standards).
• It does not include the kitchen sink (keep it simple).
• EL/IX will be extensible.
• EL/IX will be open-source.

By meeting the technical requirements of the embedded developer, using internationally accepted standards, with an open-source implementation, Red Hat intends to make the adoption of EL/IX a "no-brainer." Indeed, the impact on today's Linux developer is virtually nil. In the future it will require the maintainers of desktop Linux to incorporate the implications of EL/IX into their plans. But the impact of adopting EL/IX in the embedded community will be profound: flexibility and freedom will prevail over fragmentation. Moreover, it will provide a normalizing force that will make it easier for software developers to build content that is useful for both desktop and embedded applications, thereby expanding the market opportunity for software without increasing fragmentation.

The obvious starting point is ISO 9945-1 (Posix.1 or IEEE 100 3.1). For now, the set of functionality defined by EL/IX is small, but as this open-source initiative gains contributors, it could conceivably extend up to and beyond a complete Posix implementation and into the realm of arbitrary Linux libraries, including graphics, multimedia and others. (There are several Web sites that provide updates on Posix standards and drafts, including www.pasc.org/standing/sd11.html.)

We are starting small because we believe that the right approach to the problem is to enable the API to support configurable implementations, so configurability must be considered at the lowest level of the design.

Equally important are the Posix 1003.13 real-time application environment profiles. Consistent with 1003.13, EL/IX is divided into levels: one for deeply embedded systems, one for single-process Linux, one for multiprocess Linux and a final catchall full-Linux level. Those four levels correspond in broad scope to th e four profiles described in 1003.13.

The standard should not include functionality that is not already provided by the standard Linux kernel and glibc-we do not intend at this time to improve or provide additional functionality for Linux. Indeed, if such functionality were to result in a nonstandard version of Linux, our whole effort would be deemed a failure.

EL/IX has initially been implemented as a configurable compatibility layer on eCos, an open-source RTOS, much in the same way as Red Hat already provides an optional microITRON compatibility layer for eCos. This implementation proved two things: We can build an API that really does provide a consistent development platform regardless of the underlying operating system and thus nullify the argument about fragmentation, and secondly that we can scale that consistency down very effectively. Indeed, a customer has developed a mobile productivity product with a total kernel+API footprint of approximately 50 kbytes-well below any resul ts yet achieved with any version of Linux.

The essence of the initial implementation is to incorporate a subset of Posix 1003.1, and the complete ISO C library, math library, and optional BSD socket interface (Posix 1003.1g). Later on, we can extend EL/IX to incorporate other interesting parts of Posix and Linux and additional libraries such as OpenGL.

What is not included in the initial implementation is everything else. In particular, we do not support anything other than a single process, though multiple threads are supported. So all of the following is specifically excluded from EL/IX Level 1: process support, pipes, and fifos, process group, user or system ID support.

This is intended to be an application-level standard and we do not attempt to provide any device driver compatibility, although device access via a /dev interface is provided.

We also avoid all control terminal support. Support for file locking is also not sensible in the single-process context, so it is not supported.

In addition, EL/IX supports SCHED_RR and SCHED_FIFO scheduling policies.

The default scheduler is the eCos multilevel queue scheduler. We could consider implementing a Linux-compatible scheduler for SCHED_OTHER, or as a configuration option, but there doesn't seem to be a valid reason to do this in the embedded context. Other schedulers are configurable as per standard eCos functionality-but this is not strictly part of the EL/IX standard since this feature is not available under Linux.

Many eCos scheduler implementations should, however, be compatible with the eCos Posix threads.

Having proved the viability of EL/IX for small footprint devices (less than 100 kbytes), we have seen great interest in EL/IX le vels 2 and 3. Level 2 provides a richer set of functionality than the typical RTOS, but still provides the simplicity of a single address space with support for multiple threads.