Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Linux Software

ELC Releases Embedded Linux Standard v1.0 49

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."
This discussion has been archived. No new comments can be posted.

ELC Releases Embedded Linux Standard v1.0

Comments Filter:
  • by Anonymous Coward
    It's a GNU/Embedded Linux Standard v1.0 ;-)
  • by Anonymous Coward on Friday February 21, 2003 @08:18AM (#5351627)
    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.
    • by dreamchaser ( 49529 ) on Friday February 21, 2003 @08:28AM (#5351664) Homepage Journal
      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?
      • 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 [buy.com].

        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?
    • Why write a new one when LynxOS already exists?
    • by Anonymous Coward
      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.
    • by macshit ( 157376 ) <snogglethorpe AT gmail DOT com> on Friday February 21, 2003 @09:19AM (#5351932) Homepage
      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.]
    • 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 :)
    • ELKS [sourceforge.net] 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.

    • Ever heard of Real-Time Linux [google.com] ?

      Or about Hard Real-Time Linux [google.com] ?

    • 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!

  • by LordMazza ( 652331 ) on Friday February 21, 2003 @08:30AM (#5351677) Homepage
    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.
    • by Anonymous Coward
      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.
      • 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.
  • by Anonymous Coward on Friday February 21, 2003 @08:35AM (#5351701)
    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
  • 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?
  • Ahh... (Score:3, Interesting)

    by cybermace5 ( 446439 ) <g.ryan@macetech.com> on Friday February 21, 2003 @09:35AM (#5352037) Homepage Journal
    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.
  • Here [linuxdevices.com] 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 [thestreet.com] for the linux solution.
    • 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.
  • 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)

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Working...