Slashdot Mirror

← Back to Stories (view on slashdot.org)

ELC Releases Embedded Linux Standard v1.0

Posted by michael on from the nice-and-hefty dept.

An anonymous reader writes "The Embedded Linux Consortium (ELC) formally announced its release of the ELC Platform Specification (ELCPS) version 1.0 this week. This LinuxDevices.com Special Report includes the full text of the ELC's announcement, a whitepaper about the ELCPS standard, a newly updated "frequently asked questions" document, a roundup of news coverage, a poll, a discussion thread, and the spec itself."

49 comments

  1. *cough*, incorrect by Anonymous Coward · · Score: 2, Funny

    It's a GNU/Embedded Linux Standard v1.0 ;-)

  2. embedded Linux of limited usefulness by Anonymous Coward · · Score: 5, Interesting

    Embedded Linux vendors are making the same mistake that Sun made with embedded Java: many embedded devices are either very inexpensive or have to meet hard real time deadlines. Both of those factors make embedded Linux impractical.

    Really cheap devices go for small, older, cheaper processors and memories that can't support the relatively high processing capabilities required for Linux systems. For a hundred dollar VCR, Linux is great, but not for a twenty dollar mixmaster.

    Many industrial facilities use great numbers of embedded devices. Linux just can not meet the hard real time deadlines required. Even with the low latency and kernel preemtibility patches, Linux doesn't have the granularity necessary to ensure that hard deadlines are met. There are a couple of kludges around that allow Linux to be used on such devices, such as running virtual machines with Linux and a true real time OS and making them communicate via sockets. Sadly proprietary solutions currently fare much better. Mobile telephones also fit in this category; although expensive ones may eventually run Linux and something else, they won't run only Linux.

    With all the difficulties facing them, I can't help but wonder why the embedded Linux people bother. They would be better off writing a new OS that had lighter requirements and a design to allow it to meet hard real time deadlines. That would be a big step forward for putting the GPL in embedded platforms.

    1. Re:embedded Linux of limited usefulness by dreamchaser · · Score: 3, Interesting

      While you have some very good points, one must keep in mind the still staggering rate of performance increases in lightweight and embedded processors. No, you probably won't be able to build a $20 device that can run Embedded Linux on it effectively today, but what about next year? Or the year after that? Wouldn't it be better to have an established standard when such devices start becoming ubiquitous?

    2. Re:embedded Linux of limited usefulness by pointym5 · · Score: 1

      Why write a new one when LynxOS already exists?

    3. Re:embedded Linux of limited usefulness by Anonymous Coward · · Score: 1

      well say someone wrote a new OS which conforms to the embedded-linux API spec but has a different
      kernel and i/o layer (for hard-real-time stuff).

      it wouldn't then be linux (or gnu-linux), rather an
      elcps-compliant rtos.

    4. Re:embedded Linux of limited usefulness by macshit · · Score: 3, Insightful

      You seem to be making the mistake of thinking that there's just one sort of embedded application.

      Sure there are embedded applications and devices for which linux is probably inappropriate, but so what? Linux won't get used there. However, the word `embedded' covers a lot of ground, and there are many embedded applications and devices for which linux is a perfectly fine solution -- and that's where linux will be (and is) used.

      [Morever, as another post pointed out, the hardware used for embedded devices is continually getting more powerful, for any given application, making linux more and more practical.]

      --
      We live, as we dream -- alone....
    5. Re:embedded Linux of limited usefulness by radish · · Score: 1

      I'm seeing Java appearing in a lot of embedded devices right now - phones. Most of the new phones coming out right about now have embedded Java built right in, and it's very very cool :)

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    6. Re:embedded Linux of limited usefulness by Ed+Avis · · Score: 1

      ELKS might one day be suitable for really tiny devices with 8-bit or 16-bit CPUs, provided the application doesn't need hard real-time. (I presume a kitchen appliance falls into this category.) But nothing much seems to have happened on the project for a while.

      --
      -- Ed Avis ed@membled.com
    7. Re:embedded Linux of limited usefulness by Anonymous Coward · · Score: 0

      Thus RTLinux - low microsecond worst case real-time
      response, with any embedded Linux to back up the rest of the application/management code.

    8. Re:embedded Linux of limited usefulness by swordboy · · Score: 2, Interesting

      While you have some very good points, one must keep in mind the still staggering rate of performance increases in lightweight and embedded processors.

      Witness the proliferation ofcheap PDAs.

      The other day, I was looking into obtaining some hardware that I wanted to use in my own embedded experiments but I could not find anything that was cheap enough (read: to be profitable if I ever decided to bring my low-volume application to market). The PDA brings an interesting twist to that.

      Is there any PDA that lends itself to being hacked apart and used in something other than its intended use? The other day, I was at Lowes and I saw that their alarm system had the screen about the size of a PDA. A closer look revealed that it was running PalmOS.

      Bueller?

      --

      Life is the leading cause of death in America.
    9. Re:embedded Linux of limited usefulness by red_gnom · · Score: 1

      Ever heard of Real-Time Linux ?

      Or about Hard Real-Time Linux ?

    10. Re:embedded Linux of limited usefulness by Liquor · · Score: 1
      Ok, so I'm responding to an old post but...

      They would be better off writing a new OS that had lighter requirements...
      'Lighter requirements' is a pretty hard to define goal - contrary to many opinions, a Linux kernel configured to have only those functions that are needed for a specific application is pretty close to the smallest size that I've ever seen those functions implemented in. (At one time gcc did not optimize well, making even a simple embedded operating environment written in and for C much bigger than one hand-crafted in assembler - but now that embedded apps are getting more complex, most embedded systems are compiled with a flavour of gcc, so that's no longer relevant)

      For a TCP/IP enabled fridge magnet, you could write an application that would parse only those network packets that it was designed to handle and ignore the rest (and build and send only those packets that it needed to know about) but unless you have some programmers who are really skilled with TCP/IP,it undoubtedly costs less to just use a well developed general purpose stack such as Linux.

      The per unit cost of slightly more memory/cpu power even for millions of units is still probably less than the amortized development costs (even without time-to-market costs that could be saved with an off-the-shelf stack), especially when there's no per unit cost for the OS - After all most embedded RTOS vendors charge a per unit license fee.

      There is very little in the Linux kernel that can't be stripped out of a custom build if it isn't needed - and for an embedded device, that leaves very little overhead. On the other hand, nobody really wants to have to write custom drivers for standard components such as a USB hub.
      I tend to think of Linux as a toolkit that you can pick and choose from. It seems the embedded developers have a similar view, with the additional ability for applications to query to see what was chosen.

      ....and a design to allow it to meet hard real time deadlines


      Ok,
      SET /.MODE=RANT

      I'm just about fed up with hearing blanket statements that some flavour of Unix/Linux etc. can't do hard real time without specifying (or probably even knowing) just what needs to be run as 'hard real time'. I've implemented many small, special purpose industrial systems over the years, and most of the ones that I have had to deal with had 'hard real time' requirements in the tens of microseconds range, and I've used some flavour of *nix for implementing such systems ever since Xenix on the 286 became available.

      The things that Linux can't do is to guarantee that a user-space application will be able to respond to an external stimulus in some small number of microseconds, or will be able to access slow shared resources in some small number of milliseconds.

      So what? By most definitions of 'hard real time' then even reading data from a serial line is a 'hard real time' application in itself - if you don't read the character before the next character arrives (or the buffer fills for modern chips) it will be lost - this is a 'hard real time deadline' but nobody questions Linux's ability to do this. You don't need an actual application to buffer each individual character though, This is done by the kernel driver i.e. in the interrupt handler.

      Even with old minicomputer real-time operating systems (specifically Digital RT11) the OS couldn't keep up to sub-millisecond deadlines, so I wrote device driver routines to do the 'hard real time' functions.

      Moving to *nix systems simply kept the necessity of a device driver to handle the 'hard real time' part of the application.

      Similarly, for a lot of 'fridge magnet' applications, you don't need that high a level of real time application support - just a kernel driver for the actual physical I/O applications.

      With a pre-emptable kernel, and NO USER APPLICATIONS, just the device's linux appplication code for things like a UI, TCP/IP stack and similar $20 device requirements, application response times can still be guaranteed within fractions of a millsecond.

      Only when you get into systems with things such as user supplied apps (i.e. causes unpredictable running conditions) or resource contention (such as needing to prioritize file access on a slow device) does the application response time become unpredictable, and for the scale of many embedded (and even non-embedded) applications this is not a problem.

      Very few applications (as opposed to device drivers) need sub-millisecond response anyway. Consider that when a human is involved in the loop, anything less than about 10 milliseconds of lag is not discernable. Despite the observation in software testing (and other things) that errors predicted to occur once in a million times tend to happen 9 times out of 10 (because there is no real 'random choice' in most software), absolute timing guarantees are not often needed. But 'soft real time' capability is a necessity for any UI to be usable. I'd be unable to type this if Linux couldn't do at least that much.

      On the other hand, I've had to work with some 'hard real time' systems that guarantee absolute worst case 100 millisecond response - but cannot under any circumstance respond any faster than that!

      --

      Liquor
      Sanity is a highly overrated commodity.
  3. Re:I want Linux to run on my... by shish · · Score: 2, Funny
    Not *quite* what you're looking for, but

    this toaster

    burns the weather into your toast - done by java, maybe linux is in there somewhere though

    --
    I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
  4. A chance to compete in an emerging market by LordMazza · · Score: 4, Interesting

    Although I have some doubts about the suitability of Linux for certain types of embedded applications (where real-time OSes would probably be more appropriate), I think this is a good thing. Anything the Linux community can do to push Linux into new markets not already dominated by one company's product alone can only be beneficial. Unlike the PC market, there is no pre-existing "applications barrier to entry" into the embedded application market. The more Linux and other open software is used in any market, IMO the more it will be used in every market. Anything the community can do to foster the adoption of Linux on as many platforms as we can think of is beneficial.

    1. Re:A chance to compete in an emerging market by Anonymous Coward · · Score: 1, Informative

      I may be incorrect(hence me posting under anonymous coward :) ), but I have read on the distribution list at www.linux.org that there is a real-time version of Linux that NASA uses. Beat me with a stick if I'm wrong.

    2. Re:A chance to compete in an emerging market by LordMazza · · Score: 1

      I won't beat you with a stick because I don't know anything about a real-time Linux used by NASA, whether its existence is fact or fiction. I will say that if there is a real-time Linux then the academics at my university who specialise in embedded applications aren't aware of it (or at least weren't aware of it at the end of last year, the last time I talked to them). If such a thing exists, it'd be great, and would be even more reason to encourage the proliferation of Linux in the embedded market, which I think would be great.

    3. Re:A chance to compete in an emerging market by Anonymous Coward · · Score: 0


      There are at least a dozen of real-time linuxes around. Most of them work by placing a small RT kernel into linux, I guess thats how rtlinux (rtlinux.com) works.

      Beating the academics at your university with a stick would be a good idea.

    4. Re:A chance to compete in an emerging market by LordMazza · · Score: 1

      I will do so most certainly! Oh well, they were only Electrical Engineering academics, not Software Engineering ones. We can't all be perfect :)

  5. This spec is a good thing! by Anonymous Coward · · Score: 4, Interesting

    The ELC did good work here. They have
    produced a simple range of embedded subsets of the
    LSB, and carefully avoided inventing anything
    of their own beyond a way to query for what
    features are available. As a developer of
    embedded Linux systems, I think the ELC's
    standard is very good work -- suprisingly,
    this is an example of a vendor consortium
    that did exactly the right thing, engineering-wise.
    - Dan Kegel
    www.kegel.com

  6. Wow by mschoolbus · · Score: 1

    Links to everything you would want to read, in just one post!

    But I am just wondering, has anyone said they are going to use this specification or are they releasing it hoping someone will use?

  7. Re:Hrm by dreamchaser · · Score: 1

    Probably not. How many (non-geek) people know what OS their VCR runs? Their cellphone? Their DVD player?

  8. but so is vx-works by Anonymous Coward · · Score: 0

    and isn't it possible to make a 1MB "tiny"linux for
    small things? (i wonder how well tiny distributions will conform to the specification)

  9. Re:Wow by Anonymous Coward · · Score: 1, Interesting

    It's being adopted.

  10. linxu and CE by Anonymous Coward · · Score: 0

    hehhe embedd3d good to see now more devices? how about smaller? there'll be less, altogether more of them, but windows CE I don't think. we can say so much but TAKE THAT is more real??

  11. Ahh... by cybermace5 · · Score: 2, Interesting

    This is nice. While Linux just isn't ideal for applications requiring stringent realtime control, it's great to have some order brought to the chaos.

    A large amount of new silicon is hitting the market; the line between microcontrollers and computers keeps blurring. Some of these chips (mostly intended for the cell phone industry) run over 350MHz, include large amounts of memory, flash, and peripherals. Linux is an excellent way to manage all of that power, and ease the transfer of applications into embedded devices.

    You will have that communicator/computer you want: has all the power you need, projects onto your eye or a wall, responds to speech input, has excessive bandwidth, captures video, etc. It's within my lifetime. And with the help of some standards like these, perhaps it will run some variant of Linux. You never know.

    --
    ...
  12. The importance of Embedded linux by ftvcs · · Score: 2, Interesting

    Here is a chart of what vendors think is important when choosing an embedded OS.
    Linux already satisfies the four most popular criteria: Real Time capabilities, royalty free licensing, it runs on a variety of CPUs and it provides access to source code.

    No wonder Motorola choose for the linux solution.

    1. Re:The importance of Embedded linux by WhaDaYaKnow · · Score: 2, Insightful

      Linux already satisfies the four most popular criteria: Real Time capabilities ...

      How is that? Surely you are not speaking of the great RTLinux hack? I mean RTLinux != Linux. It _runs_ Linux and can communicate with Linux, but as far as I'm concerned this is not a solution I would choose unless I _really_ had to use Linux for one reason or an other.

      Linux itself is NOT real time and it will probably take a while (if ever) to achieve that. The kernel design is just not right for it (I'm not saying the kernel design is not right though).

      Anyways, this has been discussed several times, and I think the most important thing here is that very few embedded apps actually need real-time behaviour. I've used Linux once in an embedded system and it performed beyond expectation.

      But I wish people quit claiming Linux was real-time when it simply is not. Running an other OS which loads Linux as a sub-task doesn't make Linux real-time. And I really don't think you're going to fool any embedded developer.

  13. RTLinux--exactly! by Anonymous Coward · · Score: 1, Informative

    You are quite right; RTLinux is exactly one of the systems that I mean. It is a hard real time OS that runs Linux as a low priority thread and provides "fast and easy" communication between real time threads and Linux threads.

    I'm sure you can see why that is a bad solution. You add complexity, and make a second class Linux citizen just so that you can claim it is there. As far as using it goes, it is just a horrible nuisance.

  14. even better... by Anonymous Coward · · Score: 0

    Why not take glibc (or another one; say BSD based newlib) and write a genuine hard real time kernel to go with it? Red Hat had one, but they dropped it because they couldn't seriously support it while proclaiming, "Linux Everywhere!!!"

    As far as Linux compatibility goes, glibc is a good first step, but getting signals and devices right is a huge pain. A UNIX like kernel that resolves some of the stupidity by eliminating complicated stuff for which superior alternatives are now available would be even better. It wouldn't have the same level of source code compatiblity, but given the level of attention given to embedded devices, rewriting applications to be sane would be reasonable.

  15. Re:Hrm by Memetic · · Score: 1

    I expect anyone with one of these,DreamBox DM7000 ,does!

  16. Is the specification available in a free format? by John_Sauter · · Score: 2, Interesting

    The web site offers the specification as a PDF file, but states that it is covered by the GNU Free Documentation License. That license, reproduced in Section 9, states that the document may be redistributed provided it is editable using free tools, or is accompanied by such a version, or such a version is offered on the Web. If the consortuim offers the document only as a PDF they deny the freedom they claim to offer.
    John Sauter (J_Sauter@Empire.Net)

  17. Re:I want Linux to run on my... by Anonymous Coward · · Score: 0

    Dude, buring the weather into your toats has got to be either the dumbest or the most brilliant idea that I've seen for a while! Now if only thet could hook this up to my appointment book and remind me of my days schedule while I'm eating breakfast, I'd buy.

  18. Re:Sad news ... Stephen King dead at 55 by Stephen+King · · Score: 0, Funny

    Hey! Stop this! I'm not dead yet!

    --
    Karma: Undead.