Requirements for Embedded Linux

An anonymous reader sent in: "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes, demands on embedded Linux developers and providers are increasing. This detailed technical article by Nicholas McGuire sketches the top requirements for Embedded Linux systems including considerations of user interface, network capabilities, security issues, resource optimization, performance requirements and issues, and compatibility and standards issues."

Comments

One disadvantage of Embedded Linux -- Hackability?

[philbo]

One thing that I think may detract folks from using Linux as an embedded OS is its hackability. For example, TiVo is now hacked 10 ways from sunday. As long as it's adding hard drives and so on, the TiVo folks have been pretty cool about it, but when the encryption scheme for storing recordings was hacked, that leaves them open to legal problems.

While proprietary EOS's are more difficult (for many of the reasons outlined in the article), they can be much more secure (in the weak sense of security through obscurity) than Linux.

An important concern they left out

[Anonymous Coward]

And that concern can make or break the deal (and potentially make or break the company): Licensing.

I used to work closely with a development team that made the transition from a proprietary (and, may I add, unmaintainable and unreliable) embedded OS to Linux. Though some of the concerns in the article did come up, especially speed and size issues, those didn't hurt us much. After all, we could afford a better processor and more memory with the money we saved on royalties and maintenance expenses - these were substantial.

Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.

Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.

Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.

But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.

-Name withheld so I don't get canned

Re:An important concern they left out

[UncleFluffy]

But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications?

To which, I'm afraid, the only reply is: "Why not go write your own closed kernel - or actually pay money for one someone else has already written ?"

The whole point of the GPL is that, in return for the millions of lines of code you receive, you are expected to return the few hundred/thousand you produce. If you don't want to share, no-one is making you.

Re:An important concern they left out

[JesseL]

When it comes to embedded systems, most companies dont easily fall into hardware or software, they produce solutions that unify hw and sw. Since most hardware can easily and legally be reverse-engineered and produced in some third world country, the only thing makers of embedded systems have standing between being successful and dying from inability to compete in a commodity market is their software.

It's really very similar to Apple's market position.

Re:An important concern they left out

[selectspec]

You've hit the nail on the head for some embedded applications. We must draw a distinction between embedded systems which are tooled for a single purpose (routers, switches, storage appliances, caching appliances, accelerators, firewalls, etc), and systems which rely more on an application and service layer (PDA's, game consoles, cell phones, etc). Clearly both are technically suited for Linux, but it is unlikely that the first catagory will ever be dominated by linux given the licensing. This is especially true for the high end. Few will build a $100,000 box with GPL'd kernel modifications. The risks in building hardware are too high as it is, (because its so damn expensive todo!).

Sorry, it hasn't happened yet

[owlmeat]

"As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes"

If anything,the embedded Linux hysteria has died down quite a bit. Linux has it's share of problems in the embedded marketplace. Large memory footprint, filesystems that need time to shutdown, interrupt latency to name a few. I work in the single board computer industry and we've seen a sharp decline in the requests for embedded linux support over the last year.

Embedded vs. "desktop" perspectives

[apk]

First off, it's an excellent article covering most of the issues that arise in embedded systems -- you should at least peruse it if you're going to comment in this thread. One of the biggest issues for non-embedded developers to understand is that each development task is somewhat unique -- different hardware, I/O requirements, cost targets, time to market, etc. It's not a [relatively] standard environment like that of a typical desktop computer. In fact, the vast majority of embedded devices are "headless" -- no keyboard or monitor, so support for video drivers and/or X only impacts a very small number of applications.

My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.

There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:

• Existing non-linux OS usage (e.g., WindRiver)
• Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
• Ease/difficulty with which already-written application software can migrate to a new OS
• OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
• Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
• Product life cycle phase
• Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
• Hard real-time versus soft real-time requirement(s)
• Communications stack and protocol requirements

In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.

Andy

Embedded Linux Presentations

[Bill Kendrick]

The last two Linux Users' Group of Davis meetings have dealt with embedded Linux.

At our last meeting, a couple of cool folks from BlueMug in Berkeley came and talked about an embedded Linux prototype they built for a client (photos). Their presentation slide is also online here (2MB PDF).

At the meeting before that, Rob Wehrli of Arizona Cooperative Power came to talk about Clinux (photos). His presentation is online, too.

Enjoy!

intellectual property and embedded linux

[soldack]

This is common issue in the embedded world and sometimes is the main reason linux isn't used. I have been in a situation where linux was considered and one of the reasons it lost out was that we felt the amount of real intellectual property we could put into it was limited. We make our systems from parts that other vendors could also buy and so our software really makes a big difference. In these cases, we felt that we had to use either a BSD based system or a proprietary one that allowed us rights to change the full source. We are currently with the proprietary model but the licensing charges are keeping us looking BSD again.