| An interview with Red Hat CTO, Michael Tiemann |
Rick Lehrbaum (May 29,2000)
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.
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed