LinuxDevices.com founder Rick Lehrbaum recently interviewed Red Hat CTO Michael Tiemann, with a focus on three embedded Linux topics: (1) Red Hat's current intentions for eCos, an open source embedded OS that Red Hat inherited through its acquisition of Cygnus (Tiemann's former company); (2) the status of EL/IX, a Red Hat proposal for an embedded Linux version of the POSIX API (also produced by Cygnus);… and (3) the progress of the Linux Standards Base.

RL: Given that Red Hat is clearly the world's preeminent commercial provider of Linux, why doesn't Red Hat apply its resources to creating a highly embeddable “micro-linux” derived from the Linux kernel, instead of continuing to promote eCos?

Tiemann: Don't think of Red Hat as a “Linux company”. Really, we're an “open source company”. For example, the GNU compilers are incredibly important to our business. Open source is the common denominator.

RL: In that case, how should embedded system developers think about eCos, relative to Linux?

Tiemann: They're like a motorcycle and a house trailer (or SUV). Let's say you take your trailer, towing your motorcycle, on a vacation. You drive to a mountain in the trailer. But when you want to drive up onto the mountain, you don't use the trailer, you switch to the motorcycle. eCos offers developers an opportunity to stay within the open source realm when the application isn't appropriate for Linux.

RL: Where would you draw the dividing line between Linux and eCos? When should developers use Linux, and when should they use eCos?

Tiemann: Linux has not necessarily been factored to be a “micro-linux” yet. I'm not saying it won't happen, but it hasn't happened yet. As you know, the approach that we took last year, and the approach that we are sticking with, is that we are going to develop source level configuration technology for glibc which is a large and important component of Linux today and when we've got that model working really well and people are happy with it, we're going to apply that model to Linux. My suspicion is that even though we're working as fast and as hard as we can, we will be ready to unleash that technology on Linux before the Linux community is ready to adopt it. Now, what some companies are saying is, “we're not going to wait — we're going to start modifying the source code ourselves, and we're going to take out stuff that we know is obviously not needed in the embedded Linux space.” But when you begin to diverge from the source code, you lose the benefits of the “network effect” of the open source community.

RL: It seems to me, we'd be better off with an eCos-sized system derived from the Linux kernel.

Tiemann: Right now — and this won't necessarily be true forever — if your Flash and/or ROM space requirements add up to more than a half megabyte, then embedded Linux is probably the best starting point. If it's less than that, then eCos is probably better. However, size isn't the only issue to consider, because you can definitely have a very rich application stack which doesn't need a lot of OS functionality. Or, you may have a very small amount of software that requires exactly what's in the Linux kernel. In general, though, if you require more than half a megabyte for loading your application, Linux is a good choice.

RL: What about RAM?

Tiemann: Linux has demonstrated that it can run in a relatively small memory footprint. If you require less than around two megs of RAM, you probably don't need Linux. However, Linux is really a lot happier running with 4 or even 16 megs. So, in the range of two to four megs, it depends on the particular application. Linux supports swapping, so there's some degradation that can occur without it not working at all. In the case of eCos, which doesn't support swapping, it's much simpler: it either will or won't work.

RL: So eCos is basically appropriate for “deeply embedded” applications?

Tiemann: There are a couple more points to consider. If you need multi-processor, multiple process, or virtual memory support, then use Linux. eCos doesn't offer any of these, today. On the other hand, if you're happy to run a single application — and you can have as many threads as you want — then you can run it on either eCos or embedded Linux. You just need to determine how much of the functionality that you need is, or isn't, supported by eCos. If you're coming at this question (of eCos vs. Linux) from a truly embedded perspective, I think a better way to think about it is “can I use eCos?” Then, if you come up with a reason why it's impossible to use eCos, use embedded Linux.

RL: Well, that's obviously a Cygnus — or should I say, Red Hat — centric perspective.

Tiemann: If you take the opposite perspective, which is “can I use embedded Linux?”, you can always define your hardware generously enough so that you can.

RL: Isn't it often a tradeoff of hardware vs. software convenience? I've spent many years in the embedded-PC market, where we tended to go for the more pragmatic approach, which was to spend a little more on the hardware in order to save a huge amount on software development and support. It seems to me that most embedded microcomputer hardware has now evolved beyond to the point where you don't need to worry about using eCos — although certainly there will continue to be microcontroller applications at the very low end. What has been Red Hat's experience with design wins for eCos?

Tiemann: We're now in almost all the consumer electronic spaces we've been targeting — set-top boxes, digital imaging, laser printers, networked devices. By now, we've served over 20,000 downloads of eCos from our website, and it's noteworthy that around half the platforms eCos supports today were contributed by outsiders.

RL: To use eCos, is there anything developers need to buy from Red Hat?

Tiemann: eCos is freely available on our website. All the tools, all the BSPs, everything is there. We also support a Linux virtual target, that allows you to test your eCos software on a Linux system. We imitate the eCos hardware abstraction level at the Linux OS level, so all the thread creation, thread management, scheduling, and other normal hardware level mechanisms are actually handled at the Linux boundary layer.

RL: In other words, you emulate the eCos target application on a Linux development system?

Tiemann: What we do is emulate a particular fictitious piece of hardware, which pretends to have an x86 processor. That way you have the full set of eCos APIs available so you can write an eCos application which behaves, inside of a Linux process, the way it would behave if it were running on the actual target hardware.

RL: Which allows you to do eCos application development prior to having the target hardware implemented?

Tiemann: Yes. You can develop the eCos application on Linux. Then, when you have your hardware available, you recompile the application and it should just work.

RL: Are there any third-party eCos applications or tools yet?

Tiemann: There is some middleware. There are some networking stacks. There's a GUI builder and stack from MoJo Designs. We built a DSP library for MPEG decode/encode or MP3. At the Embedded Systems Conference, we demonstrated a prototype MP3 player that runs on a Cirrus Logic ARM processor, using our DSP library and the MoJo GUI. It has a touch screen display where you can select songs, play them, change the balance, volume, treble, bass, and listen to your favorite songs if they're loaded into Flash. By the way, it does all this without requiring any actual DSP hardware.

RL: Have any other corporate players shown an interest in jumping into the eCos market from, say, the RTOS world?

Tiemann: I don't think so. There is interest in our EL/IX API, but eCos itself has not attracted any third party support.

RL: Since you mentioned EL/IX, what's the status of EL/IX? I haven't noticed much action on it lately.

Tiemann: We updated the draft to 1.1 at the end of January. We're pushing it through the LSB (Linux Standards Base). There is interest in EL/IX from QNX, LynuxWorks, and some other commercial RTOS vendors who have been making comments and suggestions, which we're accommodating as best we can. So far, the whole process seems pretty friendly.

RL: Let's talk about the relationship between EL/IX and the other real-time Linux approaches, such as RTLinux and RTAI. Does EL/IX, like RTLinux and RTAI, involve adding a small real-time kernel that provides the real-time functionality?

Tiemann: Oh no! It's simply a way of defining functionality so it can be sliced and diced in a standard way.

RL: It has a lot in common with POSIX?

Tiemann: Oh yes! “EL/IX” stands for “Embedded Linux based on POSIX”. We're letting the real-time Linux community tell us how to make stuff actually work when it comes to real-time threads in the POSIX model.

RL: So ELIX = Embedded Linux POSIX?

Tiemann: Exactly!

RL: You mentioned the LSB. As I understand it, the LSB hasn't really accomplished much yet, other than a lot of discussion. What's your perspective its activities?

Tiemann: In Hitchhiker's Guide to the Galaxy, one of the paradoxes presented is that if people had proof of God, their belief would be fact-based instead of faith-based, and the loss of faith would cause God to cease to exist. The way Linux standards work, you've got to believe. If people believe, then standards are widely accepted. If people don't believe, then everyone's off doing their own thing. In the LSB, there's kind of a schizophrenia. There's the original people, who felt it was a good idea to standardize some aspects of Linux. Then, there's another group who want to standardize all possible conceivable aspects of Linux. I think that came as an overreaction. Right now, they're trying to decide what parts of Linux really need to be standardized. There are many different sub-components of the Linux Standards Base, some of which I think are better ideas than others.

RL: Thank you!

Related stories:
Red Hat releases eCos 1.3 open-source embedded OS
EL/IX draft spec v1.1
An interview with Red Hat CTO Michael Tiemann (Jan.'00)
Real Time Linux Gurus Take Linux to the Next Level
EL/IX: Unifying APIs for Linux and Post-PC Computing
Cygnus Moves to Pre-empt Embedded Linux Fragmentation

Want to comment on this article? Post your talkback here.

 
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.