DSP DesignLine Blog

Apple Sample

What's the deal with Embedded Linux?

Kenton Williston

5/5/2008 7:00 PM EDT

Last week Green Hills Software wrote a scathing opinion piece on embedded Linux. Here's the opening:

"Embedded Linux is the most hyped embedded operating system ever. It is promoted as inexpensive, high quality, high productivity, reliable, widely available, and well supported. It is none of these things…"

Ouch! Green Hills goes on to congratulate Linux vendors for admitting that the OS is "CHAOS" (thanks, Wind River!) and "a money pit" (you too, MontaVista!). But the praise is short-lived: According to GHS, this is a cynical ploy to scare you away from do-it-yourself Linux and turn you into a Wind River or MontaVista licensee.

That's some tough talk, but Green Hills Software is hardly a neutral observer. The company sells its own operating systems, so it stands to benefit by sowing fear, uncertainty and doubt (FUD) about Linux. Indeed, every vendor I have spoken to has taken a distinctly self-interested position on Linux. Here's a sampling of the claims I've heard:

MIPS: Do-it-yourself Linux works great! Just go to LinuxMIPS and download! Our Linux support makes us a winner!

Wind River, MontaVista: Free Linux is a disaster. Buy "real" Linux from us or you will end up crying over your keyboard!

QNX: Linux is a disaster. But our Linux-like RTOS is great!

Microsoft: Geez, why are you even looking at Linux? Life is much easier with WinCE.

Mentor Graphics: Linux? WinCE? You have to be kidding. You can get everything you want from a light-weight RTOS like Nucleus.

One thing is for sure: There is no shortage of opinions on Linux. But which vendor is telling the truth? Or are they are lying in hopes of building sales?

The reality is that each viewpoint contains elements of truth. Every project has unique requirements, so different projects call for different operating systems. Here is my (non-partisan) list of questions you should ask yourself when evaluating embedded Linux:

Do you need a full-featured OS? Embedded Linux is big; typical builds exceed 2 MB. Sure, you can shrink the OS by stripping out things like networking stacks and file systems, but these features are the main reason to use Linux. If you don't need these features, you are better off with a lightweight RTOS.

Can you get an OS with application-specific features? WinCE comes in numerous flavors, including versions designed specifically for automotive applications. (The same is true of QNX.) Nucleus has. community special features for portable media players. And so on.

What is the licensing model? The Linux General Public License has its drawbacks. What if you want to modify the kernel, but don't want share your hacks with the rest of the world? What if unauthorized code sneaks into the kernel, and the owner decides to sue? Questions like these are mainly issues for products with long life spans, like cars and network infrastructure. The rest of us can often ignore the legal issues and simply update the kernel in the next product rev.

Is Linux responsive and reliable enough? I know what you're thinking: Isn't embedded Linux specifically designed to address these points? Yes, but embedded Linux can't match OSs like INTEGRITY.

Do you want to pay now or later? Do-it-yourself Linux is royalty-free, but you have to make a major engineering investment to get it up and running. In contrast, a commercial Linux package (or a competing OS) can get you to market with minimal up-front cost.

How many units will you ship? If your volumes are low, it doesn't make sense to have your own OS team—so skip the do-it-yourself approach.

What is your time to market? The do-it-yourself approach doesn't make sense if you're in a hurry.

Is there support for your specific processor, board, or reference design? The OS with the best support will give you the lowest NRE and shortest time to market.

Will you have to port your existing code? Most projects are built on existing code. Waste too much time porting the code, and you lose the benefits of switching OSs. (You can sidestep this issue with virtualization, but that adds another layer of complexity to the system.)

Does your tool chain support the OS? If not, you will have to switch. This adds to the learning curve and makes the design team cranky. If you are willing to switch tool chains, look for OS-aware features like MIPS' Linux hot-spot analyzer.

Whatever you decide about embedded Linux, it's a good idea to take vendor claims with a grain of salt. For example, Green Hills talks tough about Linux, but the company's MUTLI IDE has supported embedded Linux since 2001. Ask yourself: if GHS really thinks embedded Linux is a disaster, why does the company support it?


print

email

rss

Bookmark and Share

Joinpost comment



Comments


David Brown

5/8/2008 4:12 AM EDT

These are all good questions to consider before choosing embedded Linux as your OS. But it's worth pointing out that they are good questions for *any* OS, not just Linux.

In particular, people often think that you have to consider licensing and legal issues as a special topic for Linux. It's not a Linux issue, or a GPL issue - you have the same sort of issues with any software you use in your system. With the GPL, the legal issues are out in the open, and are in terms that non-lawyers can understand - with commercial licenses, it is normally much harder to figure out what rights and responsibilities you have.

I'm not sure I approve of you publicly generalizing "the rest of us can often ignore the legal issues". It's certainly true that most of use can ignore some of the legal issues, such as the example threat of being sued for unauthorized code in the kernel (assuming it is not your fault!). But other legal issues, such as the requirements of the GPL, should most definitely *not* be ignored. You wouldn't expect developers to ignore the legal and licensing requirements of WinCE or QNX - why imply that they can ignore those of Linux and the GPL?

Sign in to Reply


bgat

5/8/2008 9:44 AM EDT

Nobody gets to ignore the legal issues, ever. We've been duped by the proprietary-license vendors on this topic, to our own detriment. Don't believe me? Go read an EULA, or whatever your vendors are calling their license, and see for yourself.

As far as embedded operating systems go, the Emperor has had no clothes for quite a while. The combination of its functionality and license makes Linux the kid in the crowd who points that out. The fact that Green Hills, Microsoft, etc. can respond with only "Dude, no waaaay! ... Waaaay!"-type responses is consistent with the rest of the fable.

I won't spoil the ending. :)

Sign in to Reply


Mike Perkins

5/15/2008 6:05 PM EDT

This bickering doesn't belong here. This is an online magazine, not a boxing ring for taking whacks at each other's companies. I'm actually more ashamed of Embedded.com for allowing yellow journalism on their otherwise fine website. Do us a favor - stop it. . . . Embedded.com editors, please don't allow it any longer. Please raise the journalistic bar back to where it belongs.

Sign in to Reply


Haldor

5/19/2008 3:53 PM EDT

Whatever you decide about embedded Linux, it's a good idea to take vendor claims with a grain of salt...Ask yourself: if GHS really thinks embedded Linux is a disaster, why does the company support it?

Probably because their customers have paid them to support it. Companies do all kinds of things that wouldn't make sense except that somebody with a lot of cash or clout has pushed them into it. Anybody remember the "Internet Appliance" craze? How many of those projects ever generated any profit. Ours didn't.

Sign in to Reply


Thornton

9/22/2008 11:50 AM EDT

This article reads like a conglomeration of marketing blurbs; I've heard them all from these companies. For example, see "Do you want to pay now or later?" It is patently untrue that it takes a "major engineering investment to get it up and running." It all sounds reasonable, but what happens in practice? Real data is needed from real down in the dirt developers.

I ran two projects in two years, back to back, one on embedded linux the other on INTEGRITY, identical hardware. Both projects required developers to understand the underlying ins and outs of the OS's for development and debugging, regardless of the marketing claims of GHS. It has taken more up front engineering to get INTEGRITY up and running than it took for linux. GHS provides extremely expensive training that fails to touch on the important details. Linux training is self directed, much cheaper, and more effective. Information is readily available. I suspect the relative experience would be similar for other OS's.

My Results? Spinup time for Linux development is weeks, INTEGRITY months. Developers were able to work with Linux easily. Linux typically worked "out of the box." The kernel was easy to modify and debug where needed. Configuration is a breeze. INTEGRITY was difficult to understand and had low level difficulties forcing us to work around it (and we wouldn't want to touch the kernel code even if we could.) INTEGRITY configuration is an exercise in detective work and hacking. Support? The linux community provided faster more consistent support from knowledgable developers. Real time performance? INTEGRITY has been less reliable.

No two systems are identical, but this is very close to an apples to apples comparison. Maybe Red Delicious to Macintosh; both are similar highly multithreaded, multitasking, real time systems with millisecond deadlines using identical hardware. What I cannot compare would be two systems with microsecond demands. Perhaps GHS can make good on their claim in that domain, with design and configuration done in accordance with INTEGRITY idiosyncrasies. Anyone else have real experience there?

My conclusion? Most of these companies, I am forced to assume, spend more on marketing than development and support. The theories promoted by marketing aren't backed up in practice. The bottom line is, regardless of what embedded OS you use, you had better have developers who understand it thoroughly. Do not count on any OS vendor to alleviate this issue. Such an assumption may cost you dearly. When choosing and OS, be very wary of any benchmarking data or "white papers" promoted by the vendors. Benchmarks are easily skewed to support whatever outcome is desired. Do your own benchmarking.

I have been burned by aggressive and misleading marketing. This article simply repeats much of what I've heard from OS vendors. Most of it simply doesn't match up with experience.

Disclaimer: I have no vested interest in any particular OS.

Sign in to Reply


Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm