Recently, the Embedded Linux Consortium (ELC) announced their intention to establish a “single unified specification for an embedded Linux platform” to be known as the “ELC Platform Specification”.

I was the lone dissenting voice at the ELC meeting at ESC where the board first brought forth the idea of the ELC developing and promoting a standard for embedded Linux. I therefore want to clarify my concerns.

The ELC announcement left many questions. In this document, I attempt to state many of these questions and provide some possible answers. Many of the answers are given as alternatives. I also point out what appear to be inherent contradictions in the announced goals and purposes.

I am submitting these comments in order to help contribute to the successful establishment of a standard, or standards, that will be useful to developers.

I also want to make it clear that I, personally, am in favor of a useful standard.

Here, briefly, is what I understand was announced . . .

• The specification will “avoid possible fragmentation”
  
• The specification “presents the industry with a unifying platform for pervasive computing devices”
  
• The “embedded Linux platform would constitute a viable, durable and exceptionally competitive choice for any company considering investment in today's legacy alternatives”

In further statements, Inder Singh stated that the proprietary operating system from his company (LynuxWorks LynxOS) will be compliant.

To ease the reading and writing of these notes I will take the liberty of saying “the standard” instead of “the proposed ideas of a standard.”

Here, then, is a quick list of issues . . .

1. What do we mean by “platform?”

From the description one should assume that it means that a vendor can create a source code, and perhaps a binary application, that will run on all conformant systems (hardware permitting).

For this to be possible, it means that all functions and data that are referenced outside of the application must be present, and must be compatible. This also means that references to files and data structures must be available and compatible.

Is this possible by merely defining a kernel API? I think not. We need to ensure that library routines are available as well. Does the directory “/tmp” need to be available? What about the device file “/dev/null”? Can we produce an actually useful standard without including some of these?

2. What do we mean by “Linux?”

Let's keep in mind that the Embedded Linux Consortium is proposing this. The role of the Consortium should be to promote embedded Linux.

To almost everyone, Linux means using the Linux kernel. Perhaps slightly modified. If another OS, such as VxWorks, implements the same API, do we want to certify it as satisfying the “Embedded Linux Standard?”

An embedded Linux standard should require that Linux be used. This may be a little tricky. A thought for discussion is: how about requiring that 95% of the code in the kernel be code from a released version of the Linux kernel?

3. What about other important Linux features?

Should developers be able to depend upon the ability to create kernel loadable modules? What if a developer wants to customize the networking, or provide a new file system type, or a new driver? If the standard says that kernel loadable module support is required, now the kernel internal interface becomes available. What functions and data in the kernel must be available?

Should a developer be able to assume the ext2 filesystem? The ext2 filesystem is not appropriate for some embedded devices.

The Linux kernel software is defined to allow a fair amount of customization. Which features should be required? PCI support? SMP? Low level sound? Which need not be included?

4. What about the other “advantages” of Linux?

Developers choose Linux for a variety of reasons. Included are: source code is available and free; no runtime royalties; it's more robust/reliable; excellent networking support; more drivers and tools available; lots of programmers are familiar with it. (See article on this subject.)

What about this proposed standard ensures that these advantages will survive? Nothing, as far as I can tell. As stated, the ELC proposal will allow closed source alternatives to be certified. An OS with runtime royalties can be certified; an unreliable and unrobust alternative can be certified; an OS with poor networking can be certified; an OS with few drivers and tools can be certified; an OS with a small number of trained programmers can be certified.

5. How does the standard prevent fragmentation?

Fragmentation can occur due to a number of causes, including extra features, fewer features, and changes in semantics of features. The proposed standard will address the issue of leaving out features. It will mandate that a certified OS must include the required set of features.

On the other hand, the proposed idea of a standard does not appear to address the issue of extra features, or changes in the implementation. If a vendor adds a new system call for a new time mechanism, for example, are they thwarting the standardization process? If a vendor changes the implementation of some standard item, is that conformant? Suppose a vendor re-implements scheduling to ensure true priority scheduling, or to provide priority ceilings for mutexes. Does this break the standard? Will the standard define the semantics of all of the functions? Will this definition be rigorous and precise?

Vendors of embedded Linux, as well as developers of embedded Linux devices, frequently make OS changes to better support their hardware or other requirements. This scenario is decidedly different from the environment of closed source, proprietary implementations of Unix that Posix was targeting. Linux is incredibly more amorphous in the embedded space. There are hundreds of versions of Linux for embedded systems. Vendors may have a different version for each major customer. How will the standardization work for these? If vendor X produces ten version of “Purple Cow Linux” for different platforms, and these are all undergoing continual update and development to keep up with the deluge of new software and fixes from the open source community, then how will each be certified as compliant? Do we need some new model of compliance testing?

6. How will this be accomplished in a few months?

It is my understanding that the ELC Board believes this will be relatively easy because we can simply take the Posix API's, add a few Linux deviations, and voilà — we're done. That approach means ignoring the issues I've raised above.

7. What will be the outcome if we implement this plan?

The ELC Board's idea is that we will have established a standard platform that other developers can develop to. I believe that what is being proposed is not nearly sufficient. In contrast, I believe we will accomplish . . .

• A useless standard will be produced that does not ensure that developers have a truly useful platform

• The ELC will have initially appeared to be making a useful effort but will eventually be seen as producing a useless standard, and have undermined embedded Linux

• Vendors of alternatives will be able to claim “embedded Linux standard” compliance. (For them to provide usefully compliant OS's they will need to provide the things that the standard left off. They will provide these so that they can demonstrate that real applications run on their OS.). These vendors will accomplish a marketing coup in being able to claim that, by using their OS, developers will get all the essential advantages of Linux: “We are a standard compliant OS, we have everything you need”. In addition, these vendors will be able to state that their OS provides even more: “Our OS does this and that beyond what Linux can do.”

8. Where do we go from here?

First and foremost, I think we must clearly define the objectives. What do we want to accomplish? Do we really want to define a standard “platform”? What does platform mean? What is the definition of “middleware” or “application” that we mean to satisfy?

If we determine that, indeed, the idea of a “platform” is too broad for us to be able to accomplish in the short term due to the perceived requirement to accomplish something quickly, then perhaps we should at least hedge our bets a bit and say that we are defining a “base level platform” or some such thing. Just as Posix has done. By saying that we are now defining a “base level platform” we may be able to serve the two needs of: (1) adhering to the (premature) press release; and (2) actually producing something that, in context, is useful. Continuing to call the standard “a platform” seems to me to be, at the very least, misleading.

Additionally, we need to move quickly on these discussions. We should include people in the process that have done this before. I believe it was Scott McNeil from the Free Standards Group at the ELC meeting that suggested that an important first step would be to make clear the objectives. I think that's a great idea.

We ought to obtain real data, from empirical studies, to determine what parts of the Linux environment are really needed by applications and middleware. Let's do some “straces” and look at source code. How, for example, did LynuxWorks determine what was needed for Quake to run on their proprietary OS?

Perhaps the objectives should include items like . . .

• The perceived advantages of Linux must be maintained
  
• A useful and implementable platform must be defined
  
• Middleware and application developers must find the standard to be appropriate and sufficient
  
• The standard must be completed by mm-dd-2001
  
• The standard must adhere to Posix standards whenever possible
  
• The standard must include these (x, y, z, . . .) features of Linux which
  are beyond the Posix standards (these features must then be clearly defined, both syntactically as well as semantically)

You may also be interested in reading this presentation, in which the perceived futility of one of the Posix standards is discussed. It raises many of these same issues.

---

Author's bio: Kevin Dankwardt is founder and President of K Computing, a Silicon Valley 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. He may be contacted at [email protected].

---

 
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.