LinuxDevCenter.com

oreilly.comSafari Books Online.Conferences.

We've expanded our Linux news coverage and improved our search! Search for all things Linux across O'Reilly!

Search
Search Tips

advertisement

Listen Print Discuss Subscribe to Linux Subscribe to Newsletters
Linux & Unix > Excerpts >
Building Embedded Linux Systems

Embedded Linux: Semantics and Reality

by Karim Yaghmour, author of Building Embedded Linux Systems
05/12/2003

Let's put it bluntly: embedded Linux doesn't exist. Embedded Linux is the stuff of glitzy announcements, hype, and other marketing mumbo jumbo. That is, at least, the conclusion I am forced to reach after having spent two years writing a book about the use of Linux in embedded systems, which is an entirely different subject. For had I written a book about "Embedded Linux," it would most certainly have been prime material for Marketing 101.

To understand why I make such statements, let us explore the historical and contemporary uses of "embedded Linux". Among other things, we'll tackle a question I find quite interesting: Is "embedded Linux" a noun or an adjective? Sounds silly, right? Well not quite ...

The Roots of "Embedded Linux"

One of my favorite tools for conducting an anthropological study of trends on the net is Google Groups. It's fascinating how one can select only those messages between a certain date and another, or the use of certain keywords and the absence of others. The data collected in this way can then be used to analyze the surge or drop in interest for certain subjects against actual events and trends.

On the subject of "embedded Linux", my Google Groups search was quite fruitful. For example, I was able to track down one of the oldest, if not the oldest, reference to the compound use of the words "embedded" and "Linux." The message entitled Embedded Linux kernel anyone?, sent to comp.os.linux by Bustamam Harun on the 22nd of February 1993 is of the "has anyone done this before?" type. The posting's title is quite revealing. Bustamam didn't ask about "embedded Linux," he asked about an "Embedded Linux kernel." Somehow, he found it important to mention that he was looking for an embedded version of the "Linux kernel," not just Linux. It would, therefore, seem that the first time it was ever used, "embedded Linux" was an adjective, not a noun.

Later discussions on the various groups seem to follow that same use. Take for instance the thread that starts on the 25th of October 1994 on comp.os.linux.development with a post from Trond Solem entitled Embedded Linux. This thread is interesting, as it includes some of the first instances that I can find of kernel developers discussing the use of Linux in embedded systems. In particular, Alan Cox and Ingo Molnar participate in the thread. Though the word "kernel" isn't used here, the thread quickly centers around kernel issues and there is no hint in this thread that the "embedded Linux" noun may mean anything else but the kernel.

Other messages sent during that same period in 1994 have titles such as ROMmable Linux? and 68360 linux. Even later in August 1995, when someone from CompuServe posts a message to comp.os.linux.misc entitled Embedded Linux in EPROM?, he or she asks: "Has anyone else tried to embed the LINUX kernel?" Again, the discussion revolves around the kernel.

In the following years, the compound use of the words "embedded" and "Linux" remains rather marginal until 1998. Here are the number of messages containing instances of the compound term "embedded Linux" and the loose words "embedded" and "Linux" found by Google for each year since 1992:

Year"embedded Linux""embedded" and "Linux" [1]
1992none81
19931424
1994291,160
1995321,890
1996414,320
1997476,730
19982019,190
199960819,600
20001,99029,600
20013,23053,800
20023,740199,000

[1] In some cases, the use of the word "embedded" in the same posting as the word "Linux" has nothing to do with embedded systems.

As late as 1998, "embedded Linux" is still quite often used as an adjective and there are many instances of "embedded Linux kernel" and "embedded Linux system." Even when used as a noun, "embedded Linux" quite often designates something specific, such as a distribution or the kernel itself. However, one can observe an increasing trend of the use of "embedded Linux" as a noun without reference (that is, "embedded Linux" as being a thing in itself, not a distribution, a kernel, a system, or anything else.)

The Invasion

Starting in late 1999, the year of the great Linux hype, things start to get very confusing. We start hearing about "embedded Linux companies," "the embedded Linux market," an "embedded Linux journal," "embedded Linux hardware," "embedded Linux sites," etc. In contrast, Google Groups is unable to find any reference whatsoever to "server Linux companies" or the "workstation Linux market" in its entire archive. Somehow such terms sound odd, but their "embedded Linux" variants have become mainstream. Even the straightforward "Linux server companies" only scores one message in the entire newsgroup archive. So maybe the word "embedded" is special? Well, it turns out that there are no mentions of "embedded DOS companies" and but two references to "embedded Windows hardware." It's not like these operating systems haven't been used in embedded systems before.

Nevertheless, 1999 is the year of the Linux phenomenon and that year, many companies came forth promising to rid the world of those evil proprietary embedded OS vendors by helping embedded developers use Linux in their products. The moment these companies entered the market, the term "embedded Linux" lost all meaning. It became, as I said earlier, a meaningless mishmash; the stuff of marketoids.

Related Reading

Building Embedded Linux Systems
By Karim Yaghmour

The Desert

Anyone after the invasion period trying to really understand how Linux can be used in an embedded system found himself trapped in surveying the products of a few select companies, or roaming the vast dry desert of those wanting to put Linux in an embedded system without having to rely on any vendor whatsoever.

In essence, while the number of people, magazines, sites, and guides dedicated to "embedded Linux" was certainly on the increase, the signal-to-noise ratio was getting very low. To escape the craziness, many developers roaming the "I want to understand" desert found their way to various mailing lists related to the use of Linux in embedded systems. There, many built their expertise and finally got the point where they were able to make it on their own and help others in reaching similar goals. Indeed, some of the very best information regarding the use of Linux in embedded systems is still found in mailing list archives.

While many talented souls were able to make it with mailing list help alone, many others were still left wondering where to start. Fortunately for many vendors, the use of Linux in embedded systems is nontrivial and a few of them prospered.

The situation was, however, far from ideal for those of us in the Linux community who really value freedom. I personally found it rather ironic and sad that although all of the necessary software components were available under the terms of the GPL and the LGPL, very few people were actually exercising the freedom to use this software in order to build embedded systems.

Among other things, I gradually developed a kind of allergic reaction to the use of the term "embedded Linux." Indeed, every time I see it used somewhere, I put on my "skepticism" goggles and ask myself "what's the real subject of discussion here?" or "what's for sale?"

My frustration with the ongoing hype, and the continuing lack of proper documentation, was one of the reasons that pushed me to write my book. Following the open source and free software tradition, I had a clear intention not to hide any of the most arcane tricks to the reader. I was bent on giving readers everything they needed to make it, based solely on the original source code, and to provide them with everything they needed to get the rest of the information I simply couldn't fit in the book.

Where To?

While this article attempts to break new ground and elicit discussion around the use of the "embedded Linux" term, I must confess that my book provides a very conservative definition of "embedded Linux." It remains, nevertheless, that I wish that things change.

As a first resort, I thing we should all agree that "embedded Linux" is an adjective. That would really help in narrowing down the subject of discussion. There's no way you would accept to buy something from someone selling you "big green," or "small red." There's no reason that you should buy into anything having to do with "embedded Linux," either. You would, however, know the subject of discussion if someone approached you about an "embedded Linux kernel," an "embedded Linux distribution," or an "embedded Linux system." This is why the title of my book tries to be as specific as possible: Building Embedded Linux Systems. As with any other adjective, however, there will continue to be some uses of the "embedded Linux" adjective that make little sense. I remain perplexed by those selling or looking for "embedded Linux hardware." Personally, I'm usually looking for "embedded hardware that runs Linux." It usually helps me find products rather than hype.

Secondly, I think everyone should understand that there is no special version of Linux that runs on embedded hardware. The different kernel trees developed for each architecture are all publicly available for download. In the case where you need a "special" kernel whose source doesn't come through a publicly accessible URL, then I encourage you to think twice before using it. There are, of course, a few key packages which are more often used in embedded systems, but these same packages can be used on servers and workstations all the same. Such is the case of uClibc, for example. Other packages still are exactly the same as those used on workstations and servers, but are configured differently when used in embedded systems. This is why I completely agree with Red Hat's Michael Tiemann when he wrote close to a year ago that "... Linux has the requisite DNA and development model to truly scale from embedded to enterprise as a single platform ..." Indeed, Linux's ability to scale to many different hardware configurations is one of the reasons why it's such a good choice for an embedded OS.

By exercising these two basic recommendations, I think we should be able to reclaim the "embedded Linux" adjective and return the focus back to the values at the core of the free software and open source community.

Karim Yaghmour is the founder and president of Opersys Inc., a company providing expertise and courses on the use of open source and free software in embedded systems.


Community Resource

In an effort to jump-start such changes and to help developers find a community resource on the use of Linux in embedded systems, I have set up a companion site for my book. Among other things, the site features a mailing list for discussing issues not already covered by other mailing lists. I encourage you to visit the site, to subscribe to the mailing list, and help in building a solid technical understanding of the use of Linux in embedded systems.


O'Reilly & Associates recently released (April 2003) Building Embedded Linux System.

  • Sample Chapter 5, "Kernel Considerations," is available free online.

  • You can also look at the Table of Contents, the Index, and the full description of the book.

  • For more information, or to order the book, click here.


Return to the Linux DevCenter.


What do you think? Is Karim on to something here? Share your opinion on the use of the "embedded Linux" term here.
You must be logged in to the O'Reilly Network to post a talkback.
Post Comment
Full Threads Oldest First

Showing messages 1 through 13 of 13.

  • migration kits not available for linux to vxworks !!
    2005-02-21 03:13:20  linladen [Reply | View]

    Hi all,

    VxWorks-to-Linux migration kits are offered by a number of companies, including MapuSoft, LynuxWorks, MontaVista, and TimeSys.

    But, y is there no such thing like,
    Linux-to-VxWorks Migration Kits ????

    What is the difficulty in providing such a migration kit ?
    where is the problem actually ?

    if there is a linux-to-vxworks migration kit available in any website or shop, do kindly let me know.

    I am in need of it for porting a protocol stack from arm-linux to vxworks.

    thanks and regards,
    karthik bala guru
  • Real-Time & Embedded Computing Conference
    2003-05-20 08:55:52  theoldmoose [Reply | View]

    Just thought I'd toss this in the ring for consideration:

    http://www.rtcgroup.com/rtecc/detroit/index.php

    This conference is a traveling roadshow of vendors combined with local reps. The shows are small, one-day affairs with a lot of face-to-face opportunities for those that are doing embedded projects.

    The Detroit show is next on the tour, coming up June 3, 2003. If you go to the site, you can see others that are coming up in your area. Highly recommended (and no, I am in no way affiliated with the show, or any of the vendors or reps associated with it).

    In the past few years, I've noticed an increasing Linux presence at these and at the Embedded Systems Conference. If you look at the conference schedule:

    http://www.rtcgroup.com/rtecc/detroit/conferences.php

    You will notice Linux talks are scheduled against embedded industry heavy hitters. I'll be curious to see what the ratio of attendees are for say the MontaVista talk vs the Wind River talk.

    Should be interesting. Perhaps I'll see you there.
    • Real-Time & Embedded Computing Conference
      2005-01-17 13:23:03  AdamSmira [Reply | View]

      I'll read it.
  • Great Book True Comments
    2003-05-16 12:28:16  philwil [Reply | View]


    Just thought that I'd issue a comment here.
    Great work on the book, we need many more of these. The scope and content are excellent.
    I know the commitment it takes to do this sort of venture go buy it and read it.

    I also think that the article rings true to some extent.

    The Embedded Linux hype was fostered by the hopes of Mega Bucks from any one who "owned this space". Having seen the crumbling towers from the inside out I saw attempts by many to put the Genie in a Jar.

    I am glad that those attempts failed and that the spirit of inventive cooperation is alive and well among the Embedded Linux Developers.

    I feel sympathy for those who lost their jobs and
    have had to realign their careers.

    The glossy print has faded but some new
    interesting "things" are emerging.

    1/ Many "Roll your own OS" companies are starting Linux projects. When faced with a complex System and even more complex chips the Linux solution is
    preferable to trying to catch up on your own system.

    2/ Systems using embedded Linux come ready to roll with a large number of interfaces and options already working. "Hey look, you an even log in to it ".


    3/ Commercial OS's, some of them quite good, are very expensive. They have to be, they cost a lot to create and support.

    4/ Linux is used more and more as the system of comparison at talks and sales presentations.

    I work exclusively in Embedded and Real Time Linux Training and Support. I have trained more people this year on uClinux than in the past three years combined.

    I have seen more projects started this year than in the last three combined.

    So true products based on Embedded Linux are not yet falling off the shelves but there are a great number of good systems creeping out of the woodwork.

    Phil Wilshire
    System Design & Consulting Services, LLC
    www.sysdcs.com

  • Coments on book
    2003-05-14 07:27:43  anonymous2 [Reply | View]

    If the "Embedded Linux vendor" is unable to contribute the code changes back to the originating Open Source project, that should be a warning signal, either they are too incompetent (not necessarily technically but communication wise) or client's best interests are not in their best interests.

    About the book, I think it's very nice overview of all the embedded stuff upto command line level. It might have had some small sections on real-time alternatives (real-time linux kernel, linux on top of real-time kernel, linux and real-time kernel side by side, either on top of interrupt scheduler or separate CPUs) and internationalization (C-library locale data can be huge, how to add locales, handling gettext and message catalogs).

    Some more mentions of what could be done on host machine would have been nice too, e.g. tell about using valgrind to find memory errors and leaks before going to target.
    • Coments on book
      2003-05-15 09:45:13  karim-yaghmour [Reply | View]

      Indeed, a vendor's lack of cooperation with the open source and free software community should be seen as a warning signal.

      Thanks for the comments on the book. I know real-time is one item some readers will miss. I made a decision not to discuss the subject in the book based on my own involvement in the real-time in Linux community. I've detailed the rational for this choice in an article available on the book's web site if you're interested (http://www.embeddedtux.org).

      I've noted the other items you mentioned and will take them into consideration for future versions.

      Thanks,

      Karim Yaghmour
  • I don't understand this...
    2003-05-14 02:36:34  anonymous2 [Reply | View]

    The article's author seems to be surprised that many people who mention 'embedded Linux' really mean the 'embedded Linux kernel'. I don't find it surprising though: Linux *is* only the kernel.

    The discussion of adjective vs noun is moot: Linux is a noun. 'Embedded Linux' is the same as 'Embedded Linux kernel', and is the basis for embedded systems.
    • I don't understand this...
      2003-05-16 02:26:42  anonymous2 [Reply | View]

      Very long winded article! The same can be written for Linux itself. I.e. when people refer to Linux, do they mean Linux as an operating system (kernel) or is it the broader picture (distribution).

      Rgds,
      Derek
    • I don't understand this...
      2003-05-14 06:47:26  karim-yaghmour [Reply | View]

      What I'm stating in the article is that many people _used_ to mean just the kernel, but that this isn't the case anymore. Many people today use "embedded Linux" in a very broad fashion, which has rendered its meaning difficult to identify if it isn't used as an adjective (ex: by explicitely adding the "kernel" at the end.)
      • I don't understand this...
        2003-05-15 10:56:19  anonymous2 [Reply | View]

        So what. You could have explained that in one paragraph, then got to something constructive about the subject. You spent a lot of time talking about google. No one really cares. We just care how to get either a Linux distribution or a Linux Kernel into a non-general purpose device.

        Hopefully, your next article will actually have some substance. I hope you didn't spend this much time in your book talking about this subject.
        • I don't understand this...
          2003-05-15 11:36:58  karim-yaghmour [Reply | View]

          You may personally not care, and that's just fine. There are others out there, on the other hand, that did appreciate the issues I raised.

          The first paragraph in the article made it quite obvious that this was a non-technical article, and you were welcome to skip the article if it wasn't of interest for you.

          As far as the book goes, then I encourage you to pick it up and see for yourself. Those who have already read it, including prominent open source and free software developers, have been very happy with it. See the press release for at least one example.

          As for my next article, I will discuss what I think is most appropriate. You are free not to read what I write.

          Karim Yaghmour
          • I don't understand this...
            2003-05-16 07:39:27  theoldmoose [Reply | View]

            Anonymous personal attacks should get the attention they deserve... none.

            Weblogs are necessarily editorial in nature. I find it refreshing that O'Reilly is willing to host opinion pieces and other non-technical stuff, especially when it is of importance to the geek crowd.

            If it's not your cup of tea, then just move along, nothing to see...
  • Mirrors with recent experience with 'embedded Linux' vendor
    2003-05-13 10:01:21  anonymous2 [Reply | View]

    I've had recent dealings with two sides of the 'embedded Linux' vendor participation scene:

    1) One vendor was primarily interested in using the Linux kernel as the basis for a proprietary development and application layer. It just so happened that they were the sole source of support for this particular flavor of embedded processor at the time, so (our mistake and theirs) we got in line to get the modified kernel sources, rather than take the porting effort on ourselves (after all, we wanted to concentrate on our application, not do a kernel port). Since they were so focused on their product, rather than the kernel aspect of what they were doing, it had forked rather badly from the main kernel. When the company suddenly closed its doors, we managed to get the GPLed stuff from them (barely). It was more or less useable in its then current form, but completely unsuitable for submission to the kernel tree of interest. In the meantime, the target platform evolved, making the port even more obsolete.

    2) At this point, the chip supplier stepped in, and decided that they would partner with someone else to finish the port. We waited on the sidelines for some time, until the new partner was ready to throw the GPLed code over the fence. A further annoyance was the existence of substantial sample source code freely available from the chip supplier, but with a non-GPL friendly license attached (redistribution of derived works allowed only in binary form). Talking about re-licensing or dual-licensing the code (they also had closed source customers that wouldn't be able to use GPL-only sample sources) seemed to just die out once it reached upper management levels. I also tried to convince the chip supplier to set up a communications center (weblog, sourceforge project, email list, whatever) so that all the orphaned customers of the first failed port could help each other and exchange info. This also fell on deaf ears.

    In essence, we lost about six months with all the machinations, and the project was eventually shelved, just when we were about to finally get started in earnest.

    With 20/20 hindsight, if we had spent half of that time getting our own platform up and running, we would have been much farther ahead of the game, and not dependent on outside commercial interests.


Tagged Articles

Be the first to post this article to del.icio.us

Recommended for You

  1. Cover of Linux Enterprise Cluster
    Linux Enterprise Cluster
    Print: $49.95
  2. Cover of Mastering FreeBSD and OpenBSD Security
    Mastering FreeBSD and OpenBSD Security
    Print: $49.95
  3. Cover of Classic Shell Scripting
    Classic Shell Scripting
    Print: $34.95
    Ebook: $27.99
  4. Cover of Linux in a Nutshell
    Linux in a Nutshell
    Print: $44.95
    Ebook: $35.99

Sponsored Resources

  • Inside Lightroom
Advertisement

Sponsored by:

O'Reilly Media

©2010, O'Reilly Media, Inc.
(707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
About O'Reilly
Academic Solutions
Authors
Contacts
Customer Service
Jobs
Newsletters
O'Reilly Labs
Press Room
Privacy Policy
RSS Feeds
Terms of Service
User Groups
Writing for O'Reilly
Content Archive
Business Technology
Computer Technology
Google
Microsoft
Mobile
Network
Operating System
Digital Photography
Programming
Software
Web
Web Design
More O'Reilly Sites
O'Reilly Radar
Ignite
Tools of Change for Publishing
Digital Media
Inside iPhone
makezine.com
craftzine.com
hackszine.com
perl.com
xml.com

Partner Sites
InsideRIA
java.net
O'Reilly Insights on Forbes.com